perf: align ps process-table cache TTL with the 2s consumer window
The runtime process table is read through a module-level executor cache (1s TTL) but its consumers rebuild on a 2s snapshot-cache cadence and fire constantly during a launch (every team file change invalidates a per-team snapshot). A 1s table TTL is shorter than the 2s read cadence, so 'ps -ax' was re-spawned on essentially every consumer rebuild for no freshness benefit -- a top main-thread cost in the warm launch profile (~5-8%). Raise the table TTL to 2s to match the consumer window so the spawn coalesces to at most once per consumer cycle. Safe: liveness is identity-matched (team+agent+command), not bare-PID, and OpenCode host cleanup re-validates each PID against live state before killing, so a ~2s-stale table cannot cause a wrong liveness verdict or an unsafe kill -- it only widens an already-tolerated display-staleness window by ~1s. No test asserts the TTL value.
This commit is contained in:
parent
776298b0e3
commit
2dcd5cb6a8
1 changed files with 8 additions and 4 deletions
|
|
@ -40,11 +40,15 @@ export interface RuntimeProcessTableRow {
|
|||
* very frequently (every team file change invalidates their per-team snapshot
|
||||
* caches), so without throttling here the main process spawns `ps` dozens of
|
||||
* times per second while a team runs. Those callers already tolerate ~2s
|
||||
* staleness via their own snapshot caches, and the OS process table changes
|
||||
* negligibly within a second, so a 1s window collapses the spawn storm without
|
||||
* affecting liveness correctness.
|
||||
* staleness via their own snapshot caches (AGENT_RUNTIME_SNAPSHOT_CACHE_TTL_MS),
|
||||
* so caching the table for a SHORTER window than the consumers read it just
|
||||
* re-spawns `ps` on every consumer rebuild for no freshness benefit. Match the
|
||||
* 2s consumer window to collapse those redundant spawns: liveness verdicts are
|
||||
* identity- (team+agent+command) not bare-PID matched, and OpenCode host cleanup
|
||||
* re-validates each PID against live state before acting, so a ~2s-stale table
|
||||
* cannot cause a wrong liveness call or an unsafe kill.
|
||||
*/
|
||||
const RUNTIME_PROCESS_TABLE_CACHE_TTL_MS = 1_000;
|
||||
const RUNTIME_PROCESS_TABLE_CACHE_TTL_MS = 2_000;
|
||||
|
||||
interface RuntimeProcessTableCacheEntry {
|
||||
rows: RuntimeProcessTableRow[];
|
||||
|
|
|
|||
Loading…
Reference in a new issue