feat(storage): report download throughput as per-step data via ctx.measure - #258
Merged
Merged
Conversation
Compute throughputMbps inside the `download` step and report it via ctx.measure so it lands on that step's step_data_json (first benchmark to populate per-step non-latency data). Task-level return is unchanged, so legacy results are preserved. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
Contributor License AgreementAll contributors are covered by a CLA. |
…ates as per-step data Extend the per-step measurement work beyond storage to the other benchmarks that compute a genuine non-latency metric: - ai-gateway: attach outputTokens/outputTokensPerSec to the ttft step's data (previously only in task-level data_json). - browser-throughput: emit create/connect/actions/release as pre-measured steps, with actionsPerSecond/actionsCompleted on the actions step. Latency-only benchmarks (browser lifecycle, dax build phases, sandbox TTI, snapshot-fork) are unchanged \u2014 their per-step signal is already step_latency_ms. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
…ead of fabricated step records Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Contributor
Storage Benchmark Results1MB Files
View full run · SVGs available as build artifacts |
Contributor
Snapshot/Fork Benchmark Resultssmall dataset
|
Contributor
Browser Benchmark Results
View full run · SVG available as build artifact |
Contributor
Browser Throughput Benchmark Results
View full run · SVG available as build artifact |
Contributor
AI Gateway Benchmark Results
View full run · SVG available as a build artifact |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes per-step
dataload-bearing: every benchmark that computes a genuine non-latency metric (a rate/count the framework can't infer from step timing) now attaches it to the step that produced it, so it lands inbenchmark_task_steps.step_data_jsonfor the platform to read (see benchmarks-platform#49). All other benchmarks are latency-only and unchanged — their per-step signal is alreadystep_latency_ms.storage —
throughputMbpsis a download rate, not a duration. Compute it inside thedownloadstep andctx.measureit there:browser-throughput — the session lifecycle is now recorded via real
ctx.step(not fabricated step records).runThroughputIterationwraps each realawaitphase in a step and reports throughput withctx.measureinside theactionsstep, so the runner records true timing + real success/error per phase:(Round mode's
runTaskRecordfully supportsctx.step/ctx.measure, merging framework steps with anyresult.steps.)ai-gateway — token throughput/count are non-latency, but
dns/tcp/tls/ttfb/ttftare sub-timings of a single streamed HTTP request captured via socket hooks — there's no separate awaitable to wrap, so the pre-measuredTaskResult.stepspattern is the correct escape hatch here. Attach viastep.data(the analog ofctx.measure):Rule of thumb: if a phase is its own
await, usectx.step; only hand-buildsteps[]when the sub-timings live inside one indivisible operation (ai-gateway network phases, dax build phases parsed from one script).Why not the others
browser (create/connect/navigate/release), dax (build phases), sandbox TTI (
ttiMsis a create→exec duration, correctly task-level), snapshot-fork (all*Msphase latencies) produce only durations — already captured bystep_latency_ms. Forcingmeasurethere would just duplicate latency.Testing
pnpm typecheck— cleanbench runof storage exits 0 (providers skipped without creds)Link to Devin session: https://app.devin.ai/sessions/3dbf4532c9e94ab6811ff85b49f1a203
Requested by: @HeyGarrison