Performance and scale

web/api/ListProjection sits at the web boundary and trims every list payload: it strips managedFields from every object, and ships ConfigMap/Secret data, stringData and binaryData as keys with null values. Measured on a live cluster, HTTP body bytes:

Almost all of it is Secrets, and almost none of it was ever on screen. Both the objects endpoint and the objects/watch SSE stream go through the same projection — separate code paths, one rule.

The cost is moved, not removed: opening a ConfigMap or Secret drawer now refetches the full object (16–26 ms and ~1.3 KB for a typical one; 60 ms and 948 KB for the largest Secret on the measured cluster). Every other kind’s drawer fetches nothing extra.

This is not redaction — the drawer shows every value, per ADR-001’s single-operator model. A null value renders as —, never as an empty string: "we did not send it" and "it is empty" are different claims.

The sidebar’s 118 badge numbers used to be computed as listRaw(…​).size() — a full LIST of every kind to produce an integer, re-fetched on every namespace switch. On the measured cluster (118 kinds, 1 561 objects) that was 22.1 MB of API-server traffic per call, half of it CRD OpenAPI schemas and 6.5 MB of Secret data, all decoded into heap and thrown away.

ResourceService.count instead asks each kind for one item and reads metadata.remainingItemCount:

remainingItemCount is best-effort, so its absence is branched on rather than guessed: no continue token means the page is the whole collection and the count is exact (which also covers a server that ignores limit outright), and a page that is truncated without the field falls back to a full list. A sweep comparing all 118 badges against the full object list for the same kind found zero mismatches.

The latency was never the scandal. The traffic was — and it scales with the cluster’s total content while the numbers do not.

Watch events are batched per animation frame. On connect, a watch replays the whole collection as an ADDED burst; applied one at a time that is one full table re-render per object, and it froze the tab before first paint. useResourceData buffers events and applies them in a single objects update per requestAnimationFrame.

This is a gated invariant, not a convention: useResourceData.test.ts asserts that a burst of N events coalesces into at most one update per frame, and it runs in npm run check and therefore in CI. When you add a live-updated list, add its watch to the same buffer-and-flush pattern.

Rows are virtualised from 50 objects up. Before that, one DOM row per object with real components in each — status pills, container squares, usage bars — put ~14 000 nodes and a 12 000 px table on the page at 300 objects, extrapolating to ~715 000 nodes at 15 000. Above the threshold the table windows to the visible rows.

Measured max main-thread block per list, at 200 / 1 000 / 3 000 objects per kind:

Flat, with DOM rows pinned at 20 and ~1 000–1 300 nodes at every size. Scrolling a 3 000-row list end to end costs 0–226 ms of block. Filtering is client-side and stays cheap — one keystroke over 3 000 objects is 232–353 ms, once — which is why search is not truncated server-side: a substring filter over a server-truncated page would report "no matches" for an object that exists.

Projected list payload and total request time, medians of three, at three simulator sizes:

Linear in object count, and the slowest kind at 3 000 objects is 1.2 s. The wire is not the constraint.

Once the wire and the browser were comfortable, the unbounded thing was the JVM heap, and it was worse than either had ever been. Allocation sampling with stacks (JFR) attributed a live Secrets list request:

So the expensive copies are the ones that exist before the controller runs: fabric8 buffers the entire list response into one byte[], Jackson builds a complete object graph from it, and only then is a line of kweblens code called. Streaming the reply — the fix that looked obvious — would have removed 1.4% of a Secrets list.

What works is fetching the collection in chunks and letting each chunk become garbage before the next arrives. ResourceService.listRawChunked sends limit + metadata.continue; web/api/ListJson projects and writes each page as it arrives. This is server-side paging of the fetch, invisible to the client — the response is still every object of the kind, so the list contract, the filter semantics and client-side search are all untouched. Peak heap follows the chunk size instead of the collection size.

Default kweblens.list.chunk-size is 500 (the Kubernetes convention, and what kubectl uses). Lower it on a memory-tight deployment with very large objects; 0 disables chunking and restores the single-request behaviour, which is the setting to reach for if an API server mishandles continue tokens.

Secret count per cluster, against the container’s memory limit. Not pod count, not payload size — both look healthy the whole way. Helm stores one Secret per release revision, so a cluster with a hundred pods and a couple of hundred releases can hold thousands of Secrets.

scripts/payload-bytes.mjs reports per-object and per-row bytes against a running instance; scripts/heap-probe.sh and scripts/alloc-probe.sh are the heap side. Run all of them against a live cluster.

The ratio is one API-server watch per SSE subscriber — but the number that mattered was how long a watch outlives a departed subscriber. An SseEmitter learns its client is gone only from a failed write, so a stream whose writes are data-driven held its cluster-side watch open for over five minutes on a quiet kind, and one operator walking twenty kinds in one tab held 22 open watches.

SseKeepAlive writes a :keepalive comment every 15 s; the write fails, the emitter completes and the onCompletion hook closes the watch. All four SSE endpoints attach it, and a test fails the build if a new streaming endpoint does not. The ceiling is now "one watch per list view currently on screen, released within ~30 s".

Exec-over-WebSocket and port-forward deliberately have no heartbeat: a WebSocket close frame arrives in under a second, and a port-forward is a named server-side resource that is meant to outlive the tab that started it.