📌 RTC request and IOPS cost: data for hosts #444

The request, query and IOPS cost of real-time collaboration polling, for hosts deciding whether to support RTC. Assembled from host feedback in #feature-realtime-collaboration.

Status, the proposed 7.2 direction and the Presence API path to core moved to #550.

RTC has never shipped in a WordPress core release. It was committed to trunk during 7.0 development (r61689) and cut before 7.0 shipped (r62334, #65205); neither trunk nor the 7.0 branch has src/wp-includes/collaboration/. It ships in the Gutenberg plugin, lib/experimental/collaboration/ as of v23.9.0-rc.1, behind the gutenberg-real-time-collaboration experiment. Everything below reads the plugin.

Findings

1. A solo editor sends about 840 requests and 5,000 queries an hour to establish that nobody else is on the post (§2, §3). Presence API carries that signal on a Heartbeat that already runs.
2. Two windows on the same post measure 6,360 requests an hour for one person, because awareness is keyed per connection rather than per user (§3). wp_user_id and wp_get_session_token() are available server-side and dropped before the response.
3. Moved to 📌 Tracking: Presence API path to Core #550.

The hosting team opened a call for feedback on 2026-09-24 asking hosts to test three server-aware sync engine candidates in gutenberg-sync-engines: Yjs-server, Distributed Editing (DE-RTC), and intent log. All three sit above the awareness seam, so any of them can run on wp_presence. The awareness backend is a separate axis from engine choice and the post does not mention it, so finding 1 above will not be measured unless the test instructions make the backend an explicit toggle.

1. Reported load

Reported in #feature-realtime-collaboration: a managed host's platform-side testing put RTC at 31M (best case) to 267M (worst case) additional daily requests across their fleet, against an implementation that started the poll loop on every post edit view. The model scaled observed traffic to edit URLs in scope for RTC, with idle-window and other factors layered on. The host rates their own confidence in it as medium.

Those figures were modelled before both polling intervals were widened 4x. Until WordPress/gutenberg#76704 the defaults were 1s solo and 250ms with collaborators; they are now 4s and 1s (config.ts#L45-L46). A 250ms collaborator interval is 14,400 requests per hour per client. Any figure modelled against those defaults needs rescaling before it describes current code, and the host has offered to remodel against it.

Of the cost factors named, IOPS and read latency were identified as usually the largest, so the sections below count queries per poll rather than PHP execution time.

RTC needs a cadence faster than and separate from general wp-admin presence polling, which bounds how far the two can merge. Presence can carry discovery; the editing loop still needs its own rate once active.

2. Cost per poll

Requests. One poll loop per open editor: 4s alone, 1s with collaborators, 25s when the tab is hidden (config.ts#L45-L46, #L78). At 4s that is a nominal 900 requests per hour per editor, measured at 840, authenticated POSTs, none cacheable.

Presence API adds none. It rides Heartbeat on screens where it already runs: heartbeat_received server-side (presence-api.php#L401-L404) and the heartbeat-send event client-side (presence-ping.js#L102). It has no endpoint of its own, and the only interval it sets is a wider one for idle rooms (#L44-L56).

Queries. Per room, per poll, through POST /wp-sync/v1/updates with sync-storage active, at the revisions pinned above. Not re-measured against gutenberg-sync-engines:

sequenceDiagram
    participant T as Editor tab
    participant S as WP_HTTP_Polling_Sync_Server
    participant W as wp_posts
    participant P as wp_presence
    participant C as wp_collaboration

    T->>S: POST /wp-sync/v1/updates
    Note over S,P: check_permissions()
    S->>P: SELECT awareness
    S->>W: SELECT post (cap check)
    Note over S,P: process_awareness_update()
    S->>P: SELECT awareness
    S->>P: INSERT awareness row (freshest only)
    Note over S,C: get_updates()
    S->>C: SELECT updates after cursor
    S->>C: SELECT total update count
    S-->>T: awareness map, updates, cursor
    Note over T,C: 6 queries, flat in the number of clients

Six per room per poll, on top of whatever WordPress itself runs to serve the request. Against the measured request rates in §3, that is ~5,000/hour for one editor and ~56,000/hour for three on the 1s collaborator interval; 5,400 and 64,800 if the intervals are taken as exact.

tests/e2e/polling-cost.spec.ts in this repo drives the endpoint and asserts the count is identical at one client and at three; a SAVEQUERIES dump of the three-client poll is the sequence above. The wp_posts read is a cache miss here and would be a hit on a site with a persistent object cache, so five of the six are unconditional.

Awareness is read twice because the permission check and the merge each fetch it independently (#L226, #L344).

3. One human, two tabs

Awareness entries are keyed by Y.Doc.clientID (polling-manager.ts#L1024, README.md#L178), which Yjs assigns per document instance. A second tab on the same post is a second client. Nothing in packages/sync/src coordinates across tabs: no BroadcastChannel, no navigator.locks.

flowchart TD
    A["Tab A<br/>clientID 1111"] --> R
    B["Tab B<br/>clientID 2222"] --> R
    R["room awareness<br/>2 entries, 1 person"]

    R --> H["length > 1<br/>hasCollaborators"]
    R --> L["count > limit of 3"]
    R --> M["clientId !== this.clientID"]

    H --> H2["1s interval in the visible tab<br/>3,120 req/hr measured, for one person"]
    L --> L2["4th tab never syncs"]
    M --> M2["you are your own collaborator"]

    R -.-> W["known server-side, never returned:<br/>same wp_user_id, same session token"]

Three consequences, none of which requires a second person.

The fast loop opens, and a hidden tab holds it open. hasCollaborators is set from Object.keys( room.awareness ).length > 1 on the primary room (#L727-L731) and selects the 1s interval (#L778-L784).

The interval is per tab and gated on document.visibilityState (#L422), so the second tab is usually hidden and polls at 25s rather than 1s. It still counts. A 25s interval refreshes an entry with five seconds to spare against the 30s AWARENESS_TIMEOUT applied on read (#L355), so a forgotten background tab never ages out and pins the foreground tab to the collaborator rate indefinitely.

The measured column is tests/e2e/polling-cadence.spec.ts in this repo: a real editor, real tabs, requests counted off the browser over a 30-second window and scaled. Every case lands under its derived figure, for the reason in §1: each cycle costs the interval plus a round trip. Observed collaborator gaps are 1,054-1,120ms against a nominal 1,000ms. That margin widens on a slower server, so the derived figures are a ceiling and a loaded host sheds requests rather than queueing them. The 30-second window truncates at both ends, which is coarsest on the 25s hidden row.

The hidden-tab row is measured with document.visibilityState overridden and a visibilitychange dispatched, the signal the loop branches on (#L422); headless Chromium leaves every page visible otherwise. The hidden tab sent 1 request in 30 seconds and the visible one sent 25: a backgrounded tab holds the foreground tab at the collaborator rate while contributing almost no requests itself.

The fourth tab is refused. checkConnectionLimit() counts the same keys against DEFAULT_CLIENT_LIMIT_PER_ROOM, 3 (#L398-L404, config.ts#L3). The check runs on connect only (#L385-L390), so it is the newest tab that fails to sync.

The collaboration UI renders for a solo user. isMe is clientId === this.clientID (awareness-state.ts#L304). Each tab matches only its own entry, so every other tab of yours is a stranger to it, and you appear in your own collaborator list. Open as gutenberg#78700.

Three grains of identity, all already reachable

Awareness carries only the finest one, so the client cannot tell any of them apart.

The person and device grains are both server-side, so no client cooperation is required. Two tabs in one browser share a session token and collapse server-side. One person on a laptop and a phone shares a wp_user_id but not a token: two CRDT clients, one user.

Do not return the raw token; it is the session identifier from the auth cookie. A per-room hash of it is enough to group by, and is all the client needs.

The display side is being decided in gutenberg#78700, where the thread has converged on not collapsing the list, since a second device carries its own cursor. With only the client grain available, a second device and a second tab are indistinguishable, so that decision applies to both as one preference. Returning the middle grain separates them.

The server already compares wp_user_id per client in the permission check (#L228), so the value is loaded either way. WP_Sync_Post_Meta_Storage stores and returns the awareness array verbatim (#L112-L141), so this works on default storage and does not depend on Presence API.

4. Where the two overlap

Moved to #550.

5. The reported cost factors

On cache invalidation. The site-wide last_changed bump reported in #64696 was mitigated in r62099: post meta storage now writes through $wpdb instead of the meta API, so wp_cache_set_posts_last_changed() no longer fires per awareness write (#L88-L99, #L163-L185). The ticket is open at milestone 7.2, punted there because collaborative editing missed 7.0 and then 7.1, not because a fix is in flight. The agreed direction is still moving the data off post meta onto a custom table rather than working around the meta API; gutenberg-sync-engines is that direction.

6. Candidate work

Work that lowers the cost above, roughly ordered by expected reduction within each owner.

• gutenberg Defer the poll loop until a second person is present. hasCollaborators derives from the poll response today, so the signal has to arrive on a channel that is already running; feat: add RTC collaboration hooks and server authority #290 is one. The editing loop still needs its own rate once active.
• gutenberg Reconsider the interval clamp for the solo case. getFilteredPollingInterval() clamps filtered values to the default through Math.min, added deliberately in RTC: Prevent slower polling filters gutenberg#78811 (closing RTC: remove the ability to alter polling intervals gutenberg#77500) so a host cannot slow active collaboration into feeling broken. The clamp is one-directional: sync.pollingManager.pollingIntervalWithCollaborators can be filtered down to 250ms but not up to 2s, so a host can add requests and not shed them. The rationale applies to a room with two people; for a lone editor a wider interval costs no collaborative responsiveness. Depends on the item above.
• gutenberg Return identity above the client grain, so a room can distinguish people from connections. wp_user_id is already stamped and wp_get_session_token() is already available; both are dropped before the response. Fixes the tab multiplier, the connection limit and RTC: Same user with the post open in multiple tabs appears multiple times in the collaborators list gutenberg#78700 together, server-side, with no client coordination.
• gutenberg Coalesce polling across tabs. Cheaper than the above per request, but needs client-side election; presence-poll-coordinator.js is a working reference.
• gutenberg Read awareness once per request instead of in both check_permissions() and process_awareness_update().
• gutenberg Skip set_awareness_state() when merged state is unchanged. perf: skip Who's Online payload when room state is unchanged #288 is the response-side pattern; perf: skip presence writes that would only move the timestamp #450 is the write-side one.
• gutenberg Revisit AWARENESS_TIMEOUT at 30s, which bounds any widened interval. It is a floor, chosen so a throttled inactive tab is not dropped from awareness. Raising it is safe for liveness and costly for ghosts: section 3 shows a departed client held in the room pins everyone else to the collaborator interval. Presence's 150s is not a target to copy; a stale presence row costs a stale avatar, a stale awareness entry costs the room the fast rate.
• gutenberg-sync-engines Re-measure sections 2 and 3 against it on http-polling, with the Presence API active and without, since the awareness backend changes which queries a poll runs. Both are currently measured against sync-storage at the pinned revision.
• gutenberg-sync-engines The awareness backend reads the room twice for every write, once in the permission check and once inside the write itself. Same duplicate read as the Gutenberg item above, and with the Presence API active both halves are real queries. The other half of An awareness write costs three queries per client per tick when two would do #517. #104 removes the read inside the write; the one in the permission check remains.
• presence-api Collaboration edge is only exposed to PHP, so the client cannot act on it #451. The collaboration edge reaches the client in the Heartbeat response, and as a wp.hooks action since feat: expose the room's collaborator count as JS hooks #503 and refactor: name the collaboration JS actions for the edges they fire on #511, so the editor can decide whether to start the sync loop. Prerequisite for the first Gutenberg item.
• presence-api wp_set_presence() always stamps date_gmt with now, so a relay cannot preserve the original time #452. An explicit $date_gmt on wp_set_presence() (functions.php#L504), so a caller relaying awareness for other clients can preserve updated_at.
• presence-api Consumers hand-roll an availability check for this plugin #518. A public wp_presence_is_available(), so a caller can tell an unavailable plugin from an empty room instead of checking four functions and still not knowing whether the table exists.
• presence-api Collaboration edge state writes to wp_options on hosts without a persistent object cache #512. The collaboration edge count no longer writes a wp_options row per heartbeat per room on a site with no persistent object cache.
• presence-api perf: keep the collaboration edge state in the presence table #514. It moved into the presence table behind a reserved _ prefix, so the room read a poll already makes carries it, hidden from callers.
• presence-api fix: keep a client that is still pinging out of the idle state #522. The write skip is capped at 30 seconds however high the TTL goes, so a raised TTL can no longer leave a live client's row unwritten for minutes.
• presence-api Nothing tells a consumer how stale a presence row can be #525. The 30 second cap is published in the README, so a consumer no longer has to reverse-engineer it from the source to size a liveness window.
• presence-api Every consumer writes the same loop to get its own rows out of a room #516. wp_get_presence() takes a client id prefix as a third argument, so a caller stops looping over rows that are not its own. It shipped in 0.7.0, so only a consumer supporting older versions still needs its own filtering.
• presence-api A site's wp_presence_default_ttl filter overrides a consumer's own timeout window #515. #540 stopped the filter running over an explicit argument and #541 gave that argument a date_gmt floor of its own on every read, so wp_get_presence( $room, 30 ) returns rows no older than 30 seconds under any site TTL. The backend's second ageing pass can come out.
• presence-api An awareness write costs three queries per client per tick when two would do #517. Two queries per client per tick since #542 moved the redundancy decision into the upsert. wp_presence_exchange() and wp_presence_leave() shipped in 0.8.0 (#546).

gutenberg

Three of those seven describe behaviour gutenberg-sync-engines has already changed. It ships its own copy of the polling provider and its own transport, so it can answer an item without Gutenberg answering it.

Finding 1 at the top of this issue, a solo editor spending 840 requests an hour to learn that nobody else is there, is fixed in the plugin and unchanged in Gutenberg, so that number still describes Gutenberg's own sync package.

presence-api

#451 and #452 came from #444. Six were found while building the gutenberg-sync-engines awareness backend against this plugin, each one something that plugin now works around in its own code: #518, #512, #525, #515, #517 and #516. #514 and #522 came out of this plugin's own work and change what a consumer sees.

What gutenberg-sync-engines already answers moved to #550.

7. Not established

How much deferral takes off the 31M to 267M. Depends on how often two people edit the same post at the same time, and on how often one person has the same post open twice, since section 3 shows both land on the same path. Nothing in these repositories measures either.

CPU, queueing thresholds and low-traffic cron behaviour. No harness covers this path. Both cleanup schedules exist, but WP-Cron only runs on a request, so neither is guaranteed to fire on a quiet site.