neton: update to 1.0.0-beta15 - #1465
Conversation
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f neton -t pipelined |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f neton -t baseline |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f neton -t baseline |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
1253c69 to
530d0c3
Compare
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
4197eac to
7efecd0
Compare
|
/benchmark -f neton -t baseline |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
waiting for me push new code ;) |
…TLS fail-fast, listener readiness)
7efecd0 to
1f7b48e
Compare
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
GET /async-db?min&max&limit → sequential scan of items by price range, returns
{count, items:[{id,name,category,price,quantity,active,tags,rating:{score,count}}]}.
database{} is gated by ARENA_DB (default on) so the baseline A/B can run the same
binary with the pool out; measured on a 2-core box, the idle pool costs baseline
nothing (per-req CPU flat, rps within noise). Links hyper4k + sqlx4k with
--allow-multiple-definition (both bundle the Rust runtime).
GET /fortunes → all fortune rows + one runtime-injected row, sorted by message, rendered as an escaped HTML table (row 11's <script> comes out <script>). Validated on Linux: text/html, <!doctype>, 202 <tr>, runtime row, XSS-escaped, 24KB. Baseline unaffected (route only touched by /fortunes; idle DB pool already A/B-proven free).
|
/benchmark -f neton --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
Description
Two allocation fixes on the request path, both found in a flame graph of the arena baseline.
PR Commands — comment on this PR to trigger (requires collaborator approval):
/benchmark -f <framework>/benchmark -f <framework> -t <test>/benchmark -f <framework> --save/benchmark -f <framework> -t <test> --save/benchmark -f <framework> --compare <other>/benchmark-multiple -f <fw1>,<fw2>,...-tand--savetoo; saved results land in a single commit/benchmark-multiple --save-fneeded: benchmark and save every framework the PR touches/benchmark-test -t <test><test>and save the resultsFor
/benchmark, always specify-f <framework>; the flags combine in any order. Results come back as a comment with a per-profile table of RPS, p99, CPU and memory — one table per framework on multi runs. A new benchmark comment while a run is in flight queues behind it (one deep) instead of cancelling it. For multi-framework PRs (dependency bumps, same-language refactors) prefer/benchmark-multiple, which runs everything in a single job and commits all saved results together, so no run overwrites another.--compareworks on single-framework runs only.What the deltas are measured against. By default, this framework's own results published on
main- answering "did this change help?". When you are tuning a variant or a successor entry,--comparere-bases them on another entry instead:The reply states which baseline it used, and profiles the other framework does not run show
n/arather than a delta.Run benchmarks locally
You can validate and benchmark your framework locally with the lite script — no CPU pinning, fixed connection counts, all load generators run in Docker.
Requirements: Docker Engine on Linux. Load generators (gcannon, h2load, h2load-h3, wrk) are built as self-contained Docker images on first run.