Fixed a slowdown introduced by the previous release on large, memory-constrained installs. v3.4.49 moved the app's handlers off the shared event loop so one slow page couldn't freeze the others — and that part worked: page navigation became responsive. But it also removed an accidental side effect of the old design, where the single event loop forced every request to run one at a time. With that gone, every browser tab's background health check (which runs every 30 seconds) could recompute the system-status database statistics at the same moment whenever the 30-second cache expired. On an install with a very large database and limited memory, several of those heavy recomputations running in parallel competed for the same disk cache and dragged each other down, escalating from about a second to over a minute and leaving the interface unresponsive. v3.4.50 serializes that recomputation: the first request to find the cache expired refreshes it while the others wait briefly for that single refresh (or use the just-refreshed value), instead of all of them recomputing in parallel. One refresh every 30 seconds instead of one per concurrent tab.
Behind the scenes
- A lock now guards the
/api/statusdatabase-stats and capacity recompute. The cache-freshness check happens after acquiring the lock, so a request that waited finds the cache another request just refreshed and skips the expensive queries entirely — the same double-checked pattern introduced for the row-count cache two releases ago. The lock also serializes the database connection opens in that path, which matters because each connection reserves a block of cache and memory-map space; many concurrent opens were compounding the memory pressure on the constrained box. - This is the counterpart to v3.4.49, not a reversal of it. v3.4.49's move to the threadpool was correct and stays — it's what keeps one genuinely slow page (Logs, Stats) from blocking navigation. v3.4.50 adds back bounded concurrency for the one hot, frequently-polled path that was being recomputed redundantly. The general principle: heavy work belongs off the event loop (v3.4.49), but a frequently-polled cache needs single-flight refresh so the move to real concurrency doesn't turn cache expiry into a thundering herd (v3.4.50).
- The v3.4.47 diagnostic timing fields are retained one more release to confirm this fix (expected result:
/api/statusrecompute stays bounded — around a second on a cache-miss — with no escalation under multi-tab polling). They'll be removed alongside the heavy-query optimizations still tracked as follow-up.
Operational notes
- No schema changes, no config changes, no migration.
- Expected behavior after deploy: the interface stays responsive under normal multi-tab use; the once-per-30-seconds status recompute no longer multiplies by the number of open tabs. Individual data-heavy tabs (Logs, Stats, Watchlist, Military) loading their own content remains a separate, tracked optimization.