Skip to content

test(0121): k6 script and load-test plan for the 100 req/s AC - #234

Open
stkrolikiewicz wants to merge 2 commits into
developfrom
test/0121_api-load-test-100rps-report
Open

test(0121): k6 script and load-test plan for the 100 req/s AC#234
stkrolikiewicz wants to merge 2 commits into
developfrom
test/0121_api-load-test-100rps-report

Conversation

@stkrolikiewicz

Copy link
Copy Markdown
Collaborator

Summary

  • Register the manually-issued load-test usage plan and key in manual-api-key-tier.md — the runbook's own step 5, and the only record those AWS resources exist. Plan is 150 req/s / burst 300 / 1M per month, under the stage ceiling (200/400), so 100 req/s needs no CDK change.
  • Extend price_load.js (rather than write a second harness): a low-rate warmup phase excluded from every threshold so Lambda cold starts do not pollute p95 over 30k samples; asset pool taken from 0120's fixed 20-asset list; X-Request-Id per request for a ClickHouse log_comment join; any non-200 counted as a failure; dropped_iterations as a threshold so a run that failed to sustain the rate cannot be reported as one that did.
  • setup() probes the pool and drops assets the API cannot serve, naming them in the output. Canonical USDC answers 404 (task 0178) and alone puts a permanent 5 % floor under an error rate the AC caps at 0.1 % — that is a data defect, not a load result, and it has to be excluded visibly rather than silently.
  • README records what the pool size actually selects: the gateway caches /price on the path only, so pool size is the sole lever on hit rate, and over 300 s an asset can miss at most 30 times — making 1 / 20 / 1000+ assets the ~0 % / 2 % / 100 % miss regimes. There is no X-Cache header (verified), so hit and miss percentiles cannot be tagged per request; the regimes have to be run and labelled separately. Also adds the shared-ClickHouse pre-flight ritual borrowed from soroban-block-explorer's harness, whose own runbook records that our OHLCV batch can double their p95 — the same is true in reverse.

Validated end to end against production at 3 req/s: probe dropped USDC, 19 assets under test, all thresholds green, p95 (measured phase) 83 ms. The 5-minute run at 100 req/s still needs a window agreed with BE and is not part of this PR.

Issued 2026-08-19 per the runbook's own procedure; step 5 says this table
is the only record that the resource exists. Ids and limits only - the
key value lives in the gitignored .env.local.
Warmup phase excluded from thresholds, asset pool from 0120's fixed
list, X-Request-Id for the ClickHouse log_comment join, non-200 counted
as failure, dropped_iterations as a threshold.

setup() probes the pool and drops assets the API cannot serve, naming
them: canonical USDC 404s (0178), which alone would put a 5% floor
under an error rate the AC caps at 0.1%.

README records what the pool size actually selects - the gateway caches
on the path only, so pool size is the sole lever on hit rate - plus the
shared-ClickHouse pre-flight borrowed from the block explorer harness.
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.

1 participant