[core] Warm cold e2e targets before the suite starts runs - #3590
[core] Warm cold e2e targets before the suite starts runs#3590alangenfeld wants to merge 1 commit into
Conversation
|
Sim WorldSimulated world deterministic testing for races. Traces 🟠 world-sim scenario book — 1 fail of 41 total
Full trace: |
📊 Workflow Benchmarkscommit Backend:
Streams
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 222159ms → this run 254430ms (Δ +32271ms, +15%) 📈 CRTT drill-down vs main (RTT distributions & profiles)RTT over stream progress (avg per tenth of stream, bars scaled min→max): RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max): Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max): 📜 Previous results (2)1d5bcf8Mon, 17 Aug 2026 19:36:54 GMT · run logs
Streams
83a9afbMon, 17 Aug 2026 18:58:03 GMT · run logs
Streams
ℹ️ Metric definitions & methodologyStreams: writer/reader sustained rates (steady window, 10% trimmed each side), first-chunk RTT (the stream-open path, before any buffering/backpressure), CRTT percentiles, and worst delivery stall (CDV max). Cells are medians across iterations; per-run values in the artifacts. No 🔴/🟢 marks until targets attach. The collapsed STSO distribution section above buckets every step gap, split inline (same warm process — pure framework overhead) vs queue-hop (fresh process — dispatch, reinit, replay). The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body) · Fan-out TTFS: fan-out time to first step (in-deployment start() → first of the parallel step bodies to complete) · Fan-out TTLS: fan-out time to last step (in-deployment start() → last of the parallel step bodies to complete, i.e. when the Promise.all resolves) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · CRTT: chunk round-trip time (per-chunk write → read latency, one clock domain: deployment → stream backend → same deployment) · CDV: chunk delay variation / delivery jitter (inter-arrival gap minus inter-write gap per seq-adjacent pair; skew-free; the row is each run's MAX positive value, so one stall moves it) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · Promise.all(100 steps): 100 trivial no-op steps started together in a single Promise.all; Fan-out TTFS is the first of them to complete and Fan-out TTLS the last, both from the in-deployment clientStart, so their gap is the spread the runtime adds across the fan-out · paced control (100/s, 60B): the control: 300 tiny (~60B) deltas metronome-paced at 100/s — zero workload structure, so it reads the transport floor and flush cadence, and disambiguates transport-wide vs workload-specific when a replay row moves · size sweep (100/s, 160B-12KB): same pacing as the control with deltas padded in rotation across seven log-spaced sizes (~160B–12KB) — rotation decouples size from stream position, so it isolates whether chunk size causes latency · replay gateway-gpt-5.4-nano-2000t (1x): raw provider SSE cadence captured at the AI gateway boundary (gpt-5.4-nano, the most popular gateway model; per-token deltas p50 208B = the modal production chunk size), replayed exactly as measured — the typical customer's workload; its CDV is the typical customer's real delivery jitter · replay eve-gpt-5.6-sol-2000t (1x): a captured eve turn (gpt-5.6-sol, the most-used demanding eve model; ~2000 output tokens = production p50 turn length) replayed exactly as measured — eve's envelope protocol re-ships the cumulative message so sizes ramp 142B→13KB; the demanding outlier tenant's reality · replay eve-gpt-5.6-sol-2000t (2x): the same eve capture at 2x — the headroom/stress row; real fast-tier models emit the same chunk sizes at proportionally higher rate, so time compression is a faithful speed model · first chunk (pooled): every run's seq-0 RTT pooled across all stream scenarios — the first chunk precedes any workload differentiation, so pooling samples one shared stream-open path with exact percentiles Replay cadences (semantic sha256) — eve-gpt-5.6-sol-2000t 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 All timestamps are deployment-side; runs are triggered in-deployment, so the CI runner and api.vercel.com sit outside every measured window. TTFS = Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor. |
🧪 E2E Test Results✅ All tests passed 🛠 Infra Events (absorbed by the harness)Platform anomalies the e2e harness detected and worked around (e.g. a run the queue never picked up, replaced by a fresh run). Clustered timestamps indicate a backend blip; a steady drip indicates a platform issue worth escalating.
E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 🌐 Cross-language Conformance
✅ vercel-multi-region
|
83a9afb to
1d5bcf8
Compare
alangenfeld
changed the title
A target answers HTTP well before its first run is picked up promptly, for two reasons with one shape: a fresh Vercel deployment's queue consumer takes a while to start delivering, and a local dev server pays its first flow-route compile on the first queue delivery. The run-pickup watchdog's telemetry shows the cost - stalls concentrated on the suite's first test (addTenWorkflow), waitedMs pegged at the full 15s pickup budget, timestamps right at suite start; the sidecar backends identify local-dev lanes as a dominant source alongside fresh Vercel deployments. Each stall burns pickup budget inside a test, drowns the infra telemetry in cold-start noise, and leaves the first tests one stalled replacement away from failing. warmDeployment() runs in the suite's beforeAll: it starts throwaway probe runs, abandoning (best-effort cancelling) any still pending after the pickup budget, until one is picked up or a total budget (WORKFLOW_E2E_WARMUP_BUDGET_MS, default 120s) is spent. A warmup that needed abandoned probes is recorded as a single cold-start-warmup infra event - one per suite instead of per-test run-pickup-stall noise - and an exhausted budget proceeds anyway: the per-test watchdog still guards every start, and test failures carry run diagnostics a thrown warmup would not. Signed-off-by: Alex Langenfeld <alex.langenfeld@vercel.com>
1d5bcf8 to
869e10a
Compare
1 participant
Summary & Motivation
The suite's first tests were absorbing cold-start pickup latency — a fresh Vercel deployment's queue consumer starts delivering well after HTTP is up, and a local dev server pays its first flow-route compile on the first delivery — which burned pickup budget inside a test and filled the infra telemetry with per-test stall events.
warmDeployment()runs inbeforeAll, starting throwaway probe runs until one is picked up orWORKFLOW_E2E_WARMUP_BUDGET_MS(default 120s) is spent, and records at most onecold-start-warmupinfra event for the suite. An exhausted budget proceeds anyway, since the per-test watchdog still guards every start and a test failure carries run diagnostics a thrown warmup would not.Test Plan
Unit tests cover the pickup, stall-then-pickup, and budget-exhausted paths.