FX.134 Website: /admin dashboard took 5 to 6 seconds to load after every new signup

What was wrong: the dashboard's metrics cache (a day) was dropped by every new account, email verification and license event, 100 to 230 times a day, and the recount ran in the page request: 4 seconds of it were three COUNT queries over a million session_activity rows (pageviews, visitors, app opens over 30 days). Largest Contentful Paint 5.72 s in the owner's measurement (2026-11-08).

What changed: AdminDashboard now keeps two caches. Accounts, signups, licenses and revenue (~25 ms to count) stay on the day cache dropped by audit events. Traffic is read from the stored /admin/analytics 30-day report (counted nightly by bin/warm-analytics.php), never counted while a page waits; when that report is missing or past its time the page shows what it has and starts the count in the background (bin/warm-analytics.php --days=30, one at a time, lock tmp/cache/.analytics-warm-30.lock), and says so. A fresh analytics count now replaces the stored report only when done (Cache::put) instead of deleting it first. Count again now (?fresh=1) recounts the account figures at once and starts a traffic count. Admin bar counts stopped fetching 500 library versions and 200 SuperCad inquiries to count them (LibraryVersions::countPending, SuperCadLicenses::counts). Also found: 2.45 million session files (PHP's collector is off for the custom path, 521,000 of them empty from crawlers): bin/session-gc.php + /etc/cron.d/cadcraft-sessions remove expired and empty ones daily.

Measured with the new shim bin/admin-perf.php (in-process render with every query timed, or --http against the live vhost as the test admin): cold cache 4,233 ms to 75 ms; warm 50 ms either way.

Not done: MySQL innodb_buffer_pool_size is 128 MB on a 32 GB server (session_activity alone is 646 MB), a server-wide setting for the owner; crawlers still start a session on every visit.