// the find
smallnest/go-web-framework-benchmark
:zap: Go web framework benchmark
A Go benchmark suite that spins up a trivial 'GET /hello' server in dozens of different Go web frameworks and measures throughput/latency/allocations under simulated handler work (via time.Sleep) rather than just raw routing speed. Useful for anyone picking a framework who wants to see how request overhead actually scales once a handler isn't a no-op, as opposed to the routing-only numbers from julienschmidt's classic benchmark it's inspired by.
Testing with injected sleep time to mock real handler work (DB calls, cache, downstream services) is a smarter methodology than pure routing-table benchmarks — it surfaces where framework overhead actually matters (or doesn't) once real I/O dominates. Covers a large number of frameworks (40+) including fasthttp-based ones, net/http baseline, and newer entries like goframe and indigo, so it's a reasonable one-stop comparison. Ships both static gnuplot PNGs and a genhtml Go program that builds an interactive HTML dashboard from the same CSVs, so you're not stuck squinting at flat images. Has a Dockerfile and docker-test.sh for a semi-reproducible run environment instead of requiring a hand-tuned bare-metal box.
The headline benchmark data is stamped 'Last Test Updated: 2020-05' despite a push in mid-2026 — the numbers being shown are over 5 years stale relative to current Go runtimes and current framework versions, which undercuts the whole point of a performance comparison. The README's install instructions still reference GOPATH (`cd $GOPATH/src/github.com/...`) even though the repo has a go.mod, which is a leftover from pre-modules Go and will confuse anyone following it literally. Test orchestration is entirely bash shell scripts (test.sh, test-all.sh, etc.) calling out to wrk, so there's no Windows support and no CI job re-running benchmarks on a schedule — results depend on someone manually re-running a multi-hour script on a specific VM and remembering to update the images. A full test.sh run across all frameworks takes 'a couple of hours,' and there's no way to tell from the repo how often (if ever) that's actually re-executed, so trust in the published numbers is really trust in a single stale snapshot.