Varnish polish - #1199
Conversation
take a page out of MDA2AV#1197 and disable logs. Also, lowercase `display_name` to align to the repository style.
|
👋 Heads up! This PR modifies the following frameworks:
|
|
/benchmark -f varnish --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
@MDA2AV, this looks indeed better, but I think the benchmark setup is quite noisy. Getting -4.2% while doing less work is quite weird. |
I see, there is a typical +-2-3% expected noise with these 5 second runs, pipelined being the noisiest of all, that is about as good as it gets with our current setup budget. Our "pilot" entry does hit 1-2% noise consistently with daily runs done over 60 days but it's a very stable C implementation with less than 10k lines of code running on a custom io_uring transport with fixed parameters all the way. I will trigger some more runs here so we can measure how noisy it is, server is also quite hot today because it is close to 40ºC outside here in Portugal Also I'd expect higher swings in the pipelined test, it is very difficult for that test to be stable and to be honest, it is not much of a relevant one. On techempower many entries had 10% perf swings between runs in pipelined and they had some very stable harness To increase stability we'd need to bump each run duration to 15-30 seconds at least and do best of 5 or an average, unfortunately as of today, I cannot afford increasing that because our full runs would take too long and consume too much energy, in the long run that will be improved |
|
/benchmark -f varnish |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
|
Gotcha, thank you for the context. I just wanted to make sure you were aware. I'm very grateful for your work here, and I'll take noisy benchmarks over none :-) |
|
Github actions are going through some downtime so I'll bench later. There shouldn't be a lot of noise though, at least acceptable for the type of benchmarks we cover, we also have this https://timeline.http-arena.com/#test=baseline-4096 it daily reads the current data from the site, currently we are executing bench runs on demand whenever a pr opens, if you want to measure how noisy it is you can set up a chore or open a pr everyday for a week or something and see the deltas there |
|
Oh, very nice, thank you! |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f varnish |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f varnish |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
take a page out of #1197 and disable logs.
Also, lowercase
display_nameto align to the repository style.Description
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, ghz) are built as self-contained Docker images on first run.