DeepSeek Harness dsh web: 12s reconnect, 1-core main thread

DeepSeek Harness (DSH)'s dsh web has two typical "always busy" appearances whose symptoms point in exactly opposite directions: one is the connection being busy—the panel flashes "connected" about every 12 seconds, the browser sees code=1006 and an abnormal closure, and it is really the heartbeat mistaking a large snapshot transfer for a lost peer and rebuilding the connection repeatedly; the other is the CPU being busy—the node process's JS main thread pins about 1 core, the process reaches over 2 cores, and the memory peaks at over a dozen GB, from three stacked hot paths: session-log cold reads, the projection cache being cleared wholesale, and settings describe having no cache. The key to the former is that the judgment window is set by the heartbeat interval and the allowed number of misses together, and the key to the latter is that cold reads are amplified by high-frequency polling—so both can be solved by "fix the variable first, then tune the parameter", without waiting for a core change (#9603, #9517).

DSH plugin reconnect every 12 seconds: the heartbeat mistakes a large snapshot for a lost peer

One-line conclusion: the heartbeat demands a reply at a fixed interval and terminates the connection after two misses in a row; a several-MB session-history snapshot can occupy the event loop beyond that judgment window, the reply is not processed in time, so the server disconnects—and the frontend reconnect triggers the next snapshot, forming a self-sustaining loop. The symptom is the panel repeatedly flashing "connected" and the browser showing code=1006 with wasClean=false (#9603).

DSH plugin first rule out two common misreadings

These two matter—they can save you half a day of investigation (#9603):

1. It is not a backpressure problem: this implementation uses a generic WebSocket library, not a server framework with built-in backpressure control, so the "connection got written full" direction does not hold;
2. Don't be led astray by a "file-size threshold": a rule-of-thumb threshold like 68KB–1.6MB appeared in the discussion and was later confirmed to be a coincidence—the real criterion is "does the drain time exceed the heartbeat window", not some fixed size (#9603).

DSH plugin three-step diagnosis and handling

1. Confirm it is a false positive, not a real network drop: on a short link (same machine or LAN) everything is fine, and the ~12-second flashing only appears on a slower link or with a larger snapshot—that is this entry (#9603).
2. Raise the heartbeat interval (deployment side, most direct):

# In the gateway/typert-related config
websocketHeartbeatIntervalMs: 15000

The discussion confirms this parameter is public and documented in the README (#9603).

3. Reduce the size of a single snapshot: follow fewer sessions at once, and avoid re-sending the full snapshot for already-stopped sessions—the discussion notes this is the fix closer to the root cause (#9603).
4. Don't try chunked sending: chunking within one response is illegal at the protocol level, is a protocol-extra approach, and does not constitute a solution (#9603).
5. Verify: after tuning, stay for several minutes on the link that used to flash off, and expect no more periodic "connected" prompt (#9603).
6. The known cost: after raising the heartbeat interval, real disconnections are discovered more slowly—that is the trade-off against "fewer false positives" (#9603).

DSH plugin main thread pinned at 1 core: three hot paths + one amplifier

One-line conclusion: the main thread is continuously occupied by three hot paths—session-log cold reads (full decompress + line-by-line parse), the projection cache being cleared wholesale, and settings describe having no result cache; and "a mobile app polling at a few seconds' interval" is the amplifier. The symptom is a single process pinning about 1 core of JS main thread for a long time, the process reaching over 2 cores, an RSS peak of over a dozen GB, and even getting killed by a timeout signal (#9517).

DSH plugin the three hot paths, taken apart

DSH plugin one caution: don't write a retracted conclusion into your investigation

The conclusion "the cache capacity is hard-coded and not configurable" was retracted by the reporter himself—that parameter is in fact a public config option with a fairly small default. So if you see "the capacity is hard-coded" elsewhere, don't carry it forward (#9517).

DSH plugin four-step deployment-side handling

1. Set the prepared cache size to be no smaller than the session count:

preparedSessionCacheSize: 64   # set per your actual session count, at least no smaller than it

2. Stop the sub-second polling: if a mobile or monitoring client polls at a 7–9-second interval, turn it off or lengthen it first—this is the key step to turn cold reads from "continuous" into "occasional" (#9517).
3. Follow fewer sessions at once: open fewer panels/tabs to avoid concurrent cold reads (#9517).
4. Verify: watch the process's CPU usage with a system monitor. In the discussion, after the reporter made changes in these directions locally, the main thread went from 0.99 core to 0.12–0.13 core (about 12x) (#9517).
5. Note it is distinct from the memory entry: this entry's crux is a CPU hot path, a different family of problem from "a memory leak causing OOM", so don't mix them up when investigating (#9517). Likewise, the "fully blank screen, wrong content" family lives on the rendering side and should not be mixed with this performance/connection family either — see DeepSeek Harness web UI: folded text, blank, KaTeX, 404.

DSH plugin troubleshooting notes

These two look far apart, but they share one investigation framework: first fix the "variables" (link quality / polling frequency / session count), then look at the "parameters", and only then suspect an implementation defect. Eight points:

1. Do the contrast first: short link fine, slow link flashing = a heartbeat false positive; turning polling off lowers the load = cold reads being amplified (#9603, #9517).
2. Don't treat a size threshold as a criterion: that 68KB–1.6MB rule of thumb is confirmed to be a coincidence (#9603).
3. Chunked snapshot sending is not a solution (illegal at the protocol level) (#9603).
4. Raising the heartbeat means accepting the cost of "slower disconnection detection" (#9603).
5. Reducing the full snapshot for "already-stopped sessions" is closer to the root cause; do it first (#9603).
6. Polling is the amplifier: turn the polling off before evaluating other measures (#9517).
7. The cache capacity is a public config option; don't carry forward the old "hard-coded" claim (#9517).
8. State the fix status honestly: both are unfixed in the version the discussions refer to (0.2.0-rc.2); websocketHeartbeatIntervalMs and preparedSessionCacheSize are public config options (you can adjust them yourself), while "reduce the full snapshot for already-stopped sessions" and "add caching to settings describe" are core-side changes.

dsh web's performance problems are often directly tied to "how much you have open at once", and the number of plugins and install/uninstall actions are among the variables. If you want to rule out that plugin layer first, instead of typing commands everywhere, use a visual plugin marketplace such as DSH Plugin Hub: the installed list, install/uninstall history, and system logs are all in one panel.

Source: Discussion #9603, Discussion #9517.