Produce a scale analysis and benchmark before the core proposal

[josephfusco]

The current write behavior -- unconditional upsert on every heartbeat tick per user -- has not been benchmarked or analyzed for impact at realistic concurrency levels.

Before this becomes a core proposal, there should be a documented answer to: what does the wp_presence table look like under 100, 500, and 1000 concurrent admin users? What are the query times, lock wait times, and table size at those levels with the 60-second TTL and the per-minute cleanup cron?

This does not require a solution to the write volume question -- it requires evidence. A tested environment with realistic data that shows either the current design handles expected load acceptably, or that specific numbers justify the engineering changes tracked in #131.

Without this, the core proposal will face the question at review time without a prepared answer.

[josephfusco]

This issue was identified as part of a peer review conducted by Claude Sonnet 4.6, facilitated by @josephfusco.

[jigneshbhavani]

I'd like to take this one.

One thing worth settling before picking numbers to chase: the table is bounded by concurrency, not by elapsed time. Each user holds one admin/online row plus one per post editor they have open, and cleanup drops anything past the 60s TTL every minute (includes/functions.php:456 and :467 cap it at 1000 rows times 10 passes). So 1000 concurrent admins is on the order of 1000 to 2000 rows, which is small. If that holds, table size isn't where the answer is, and the numbers that matter are write contention on one hot table and what each tick costs to read.

On method, since the issue doesn't specify: I'd drive the real heartbeat endpoint with N concurrent workers rather than simulating the writes, so the per-tick read path is included, and report query and lock wait times at 100 / 500 / 1000 with the cleanup cron running against them.

Flagging one overlap: #205 covers the uncached aggregates on every tick and is already assigned. If the read side turns out to be the headline here, that's its territory rather than mine, so I'll keep to measuring and hand over anything it should own.