PlyComparison
How Ply compares with Gin, Echo, Fiber and net/http
Framework Comparison
Ply is a thin layer over fasthttp. That single sentence explains most of its performance profile: it inherits fasthttp's throughput and keeps the layer on top as small as possible, while adding zero-allocation routing and a set of built-in engines.
It does not claim to be the fastest framework in every benchmark. The honest summary is:
- throughput at fasthttp parity: within 3% of fasthttp and within 2% of Fiber v2/v3 in the thread-matched run, and in the same band at oversubscribed concurrency.
- the thinnest framework layer we measured: in-process, Ply is within 4% of a bare path-plus-switch handler and about 37% cheaper than Fiber.
- features that other frameworks expect you to assemble from plugins.
Architecture
| Ply | Gin | Echo | Fiber v2/v3 | net/http | |
|---|---|---|---|---|---|
| HTTP engine | fasthttp | net/http | net/http | fasthttp | net/http |
| Route dispatch | compiled switch + radix fallback | radix tree | radix tree | radix tree | ServeMux |
| Path params per matched route | 0 allocations (inline slots) | not measured here | not measured here | not measured here | n/a |
| Response/request context | pooled, zero-copy | pooled | pooled | pooled | per-request |
| Built-in queue, pub/sub, cache | yes | no | no | no | no |
| Test without opening a port | app.Test | httptest | httptest | app.Test | httptest |
| Middleware, groups, templates, validation | yes | yes | yes | yes | partial |
Measured throughput
GET /user/42, 6C/12T laptop, wrk on the same host, round-robin reps,
median of 3 (full method and spread on the benchmarks
page):
| Framework | c=200, t=6 | c=512, t=12 |
|---|---|---|
| fasthttp | 453,821 | 462,022 |
| Ply | 442,483 | 450,054 |
| Fiber v2 | 446,904 | 453,277 |
| Fiber v3 | 439,446 | 441,530 |
| net/http | 285,608 | 296,132 |
| Chi | 263,415 | 275,713 |
| Gin | 264,289 | 275,065 |
| Echo | 256,752 | 270,836 |
Two things are structural and repeat across runs:
- Everything built on fasthttp is roughly 1.6x faster than net/http, Gin, Chi and Echo under load.
- Ply and Fiber sit within a few percent of each other. At oversubscribed concurrency the spread reaches ±15%, which is larger than the difference between them, so we do not claim a win there.
Measured overhead
In-process (no sockets, no syscalls), invoking each framework as a
fasthttp.RequestHandler with a reused context, median of 3 runs:
| Case | ns/request |
|---|---|
| bare fasthttp, path + switch | 173 |
| Ply, param route | 180 |
| Fiber v2 | 287 |
| Fiber v3 | 305 |
Ply's router, context pool, middleware chain and recovery together cost about 7 ns more than the hand-written baseline, i.e. nothing measurable at network scale. That is the property we optimize for: the framework should be invisible.
When to choose what
- Ply: you want fasthttp-level performance without dropping to raw fasthttp, plus built-in queue, pub/sub and cache engines, zero-allocation params and an in-process test helper.
- Fiber: you want the largest ecosystem and community around a fasthttp-based framework.
- Gin / Echo / Chi: you want the standard
net/httpecosystem (http.Handlerinterop,httptest, third-party middleware) more than raw throughput. - Raw fasthttp: you want the maximum possible throughput and are happy to write routing and context plumbing yourself.
If you need net/http middleware compatibility, none of the fasthttp-based
frameworks will fit perfectly; that is an engine-level trade-off, not a
routing one.