update mq-bridge, add crud, fortunes - #1312
Conversation
|
/benchmark -f mq-bridge |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
/benchmark -f mq-bridge --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
| //! endpoints degrade rather than blocking the cleartext profiles. | ||
|
|
||
| #[global_allocator] | ||
| static GLOBAL: mimalloc::MiMalloc = mimalloc::MiMalloc; |
There was a problem hiding this comment.
Not so sure but this seems to be more of a tuned change to me. I am not too much into Rust and mimalloc seems stable enough to ship to production, so I guess this is fine - just a thing to consider maybe.
There was a problem hiding this comment.
Hm. Yes - this is probably alredy a tuned setup. Mimalloc isn't completely standard - even if stable.
I mostly oriented on the trillium setup. It is also using mimalloc. Also in the not tuned version:
https://github.com/MDA2AV/HttpArena/blob/main/frameworks/trillium/src/main.rs#L2
There was a problem hiding this comment.
So - I just removed mimalloc. Will check via bench if this makes a big difference.
Anyway - if this is an issue, trillium should probably also remove mimalloc.
|
/benchmark -f mq-bridge |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
5ee0aa4 to
d9c32e5
Compare
d9c32e5 to
74755ac
Compare
|
/benchmark --save |
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Benchmark ResultsFramework:
Full log |
|
Using Edit: Checking again - mimalloc also significantly increased memory consumption. So - it was probably better for throughput, but not good for the final resulted score. Will evaluate - I think I will make a lib change to improve performance without mimalloc. |
Description
Updating mq-bridge to latest version.
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.