Skip to content

Add nightly high-load topic stability runs - #658

Open
polRk wants to merge 13 commits into
codex/topic-slo-integrityfrom
codex/topic-nightly-stability
Open

polRk wants to merge 13 commits into
codex/topic-slo-integrityfrom
codex/topic-nightly-stability

Conversation

@polRk

@polRk polRk commented Oct 9, 2026 •

Copy link
Copy Markdown
Member

What

Run four-hour topic stability tests on Node.js 22/24/26 and Bun without an RPS cap, with bounded pending messages and real login-token renewal over TLS. Stacked on #657; infrastructure support is in ydb-slo-action#77, targeting v2.

Changes and reasons

  • Four producer workers feed one reader across 24 partitions with 32 KiB payloads and mixed RAW/GZIP/ZSTD codecs. Each worker owns its driver and clients. Reader commits release an equally divided 8,192-message budget, so backpressure bounds retained work instead of lowering a configured RPS target.
  • Set the topic write quota to 50 MiB/s per partition, avoiding the low default quota. Limit retention to 512 MiB per partition and the workload container to 6 CPU / 12 GiB for the 24 CPU / 72 GiB / 93 GiB runner.
  • Compare throughput and retained memory across windows after five minutes of warmup. Record acknowledged-but-undelivered backlog, sampled reader supply and process CPU time. These distinguish inadequate producer supply from a fully supplied reader; throughput includes verification, commits, network and YDB and is not claimed as an isolated runtime ceiling.
  • Use five-minute login tokens. Each worker must see a changed token acknowledged on an existing stream, followed by successful data traffic after the old token expiry. Reconnect-only authentication does not qualify.
  • Keep per-worker heap/codec memory measurements and process-wide RSS. RSS and CPU time are not summed across workers. Reconcile all final producer checkpoints with reader delivery and commit before reporting success.
  • Preserve source/runtime/image identity, results, logs and metrics for 14 days. The image retains ENTRYPOINT ["node", "index.js"]; the Bun base image already maps node to Bun.

The daily schedule is 22:17 UTC. Manual runs select a runtime and duration of 20 minutes to four hours. No chaos or baseline workload is started.

Testing

  • 1,299 unit tests pass; all 34 workspace builds pass; lint passes with existing repository warnings. Changed-file formatting and workflow YAML parsing pass.
  • New controls cover full-window backpressure, cancellation, duplicate commit notifications, multi-producer checkpoint reconciliation, throughput degradation, reader supply, expired/long-lived tokens and reconnects that must not count as renewal.
  • Live Node.js 24.19.0 over TLS, 390 seconds: 2,859,015 accepted = acknowledged = delivered = committed messages, no duplicates, no remaining work and no reconnects. All five workers pass two 30-second windows after the normal five-minute warmup. Reader throughput is about 7.4–7.6k messages/s with acknowledged backlog in every post-warmup sample; RSS window-minimum growth is about 50 MiB.
  • The reader and all 24 writer streams acknowledge a changed login token and continue past the old token expiry. The first control exposed the reader's unchanged-token ACK deadlock; the regression and fix are in Fix topic lifecycle and bound retained memory #656 and inherited through the stack.
  • Bun 1.4.2 completes a 30-second functional control: 216,738 messages reconciled, no duplicates or reconnects. Its process RSS reaches about 3.7 GiB and reader JavaScriptCore extra memory about 2.5 GiB. This control had stability checks disabled and does not qualify memory stability; the nightly 2 GiB RSS limit rejects that level.
  • A separate earlier 1 KiB / four-partition control with a 30-second warmup failed the RSS growth check (+266 MiB). Its failure evidence is retained; it is not counted as a passing stability run.

Local YDB runs in AMD64 containers under emulation; the workload runs on native ARM64. These controls verify behavior, not target-runner throughput. The full four-hour matrix on the target runner has not run. Scheduled runs start when the workflow reaches the default branch. Earlier Bun 1.4.2 runs exposed TLS-related memory growth; this profile preserves failure checks rather than suppressing that failure.

Checklist

  • Private test infrastructure only; no changeset or public SDK API change
  • Existing SLO documentation updated

@polRk
polRk added this pull request to stack #659 October 9, 2026 10:55
- uses: actions/setup-node@v6
with:
node-version: '24'
- uses: oven-sh/setup-bun@v2
@polRk polRk changed the title Add nightly TLS topic stability runs Add nightly high-load topic stability runs Oct 9, 2026
@polRk polRk added the SLO label Oct 10, 2026
@github-actions github-actions Bot removed the SLO label Oct 10, 2026
@github-actions

Copy link
Copy Markdown
Contributor

🌋 SLO Test Results

🟢 4 workload(s) tested — All thresholds passed

Commit: e7e1779 · View run

Workload Thresholds Duration Report
node-kv 🟢 OK 15m 2s 📄 Report
node-kv-2dc 🟢 OK 15m 2s 📄 Report
bun-kv 🟢 OK 15m 2s 📄 Report
bun-kv-2dc 🟢 OK 15m 3s 📄 Report

Generated by ydb-slo-action

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants