Performance: every page view reads, decodes and rewrites the whole view counter under one lock
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- php
- Domain
- backend, performance
Research direction
Read base.php at hypha_incrementStats() and hypha_getStats(), then trace how flushDigest() consumes the counter. Check the existing handling of data/hypha.stats and the proposed data/hypha.stats.log behavior, including period boundaries and cleanup. Done means views append short period timestamps and digest reads add and discard reported periods; pull request #678 is already open against this issue.
Written by the indexing model from the issue text.
Description
Part of #411.
Problem
Every page view by a visitor runs hypha_incrementStats() (base.php), which:
- takes an exclusive lock on
data/hypha.stats; - reads and decodes the whole JSON file;
- adds one;
- writes the whole file back through a temporary file and
rename().
All views of the site wait for each other on that one lock, and the file grows with every digest period. Under load on a bind mount (Docker Desktop on macOS), the rename() also briefly hides the file from a parallel fopen(), which then fails with a 500 (Cannot lock file data/hypha.stats, open failed).
The count is only read once per digest period, by flushDigest() through hypha_getStats().
Proposal
- Append one short line (the timestamp of the period) per view to
data/hypha.stats.log, withFILE_APPEND | LOCK_EX: the lock lasts microseconds, and nothing is read. hypha_getStats()adds the lines of the period to the old count inhypha.stats, and then drops the lines of periods that have been reported, so the log stays small.
- Dominant language
- JavaScript
- Stars
- 5
- Forks
- 9
- Avg merge
- 18h 49m
- Merged PRs (30d)
- 13
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PlanBCode/hypha
-
Component: User interface Impact: Low Level: Easy Pagetype: Peer reviewed article Type: Bug Value: Visitors
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Impact: Medium Level: Easy Type: Bug Value: Users
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Impact: Low Level: Easy Pagetype: Festival Type: Bug Value: Coders
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Impact: Medium Level: Easy Pagetype: Mailinglist Type: Bug Value: Users
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day
-
Impact: Low Level: Easy Type: Bug Value: Coders
Difficulty 1/5 1-3 hours Newbie friendliness 85/100
PlanBCode/hypha#586 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Upgrade listener stays on a custom server after close when `preClose` is setPossibly taken @RaphaelFakhri claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
fastify/fastify-websocket#388 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
DietrichGebert/ponytail#1343 ·
Maintainers usually reply within 1 day
-
cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
swombat/souls-house#770 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day