Fiber v2 vs v3 benchmarks
In-process request benchmarks. All versions run interleaved on the same CI machine, each with its own API and dependencies.
Overview
Requests per second on one CPU core, measured in-process with HTTP parsing but without serializing the response or the network. Higher is better.
Change in time per request
Details
Reading the numbers
- Requests per second are one divided by the median time per request on a single CPU core, from parsing the request to the end of the handler. A real server also serializes the response and sends it over the network, so production throughput is lower.
- Each round runs every version of a scenario back to back, rotating which goes first. A time change is the median of the per-round ratios against v2, so load on the CI host that hits both halves of a pair cancels out. It can differ slightly from the ratio of the two medians.
- Thin gray bars and ~ mean no significant difference: the sign-test interval of a time change includes zero, or benchstat found p ≥ 0.05 for memory, allocations and snapshots from before paired rounds. A run whose median interval is ±10% or wider gets twice the rounds.
- Compare versions within one snapshot. CI machines differ between snapshots, so absolute numbers do not carry over.
- Each version is built several times with different function layouts, and the rounds cycle through them. Where the linker puts a function changes a cheap scenario by tens of nanoseconds on these CPUs, so without this a lucky layout would look like a win.
- v3.0.0 and main build with the dependencies they ship with, main at its latest commit when the snapshot ran. Snapshots that compare only v2 and v3 built each request through setters and left out HTTP parsing.
- Snapshots started by hand can add main on the latest commit of fasthttp master, to show unreleased fasthttp changes before Fiber pins them.
fasthttp_onlyruns no Fiber code and shows what the fasthttp version alone changes.