vanilla-epoll

Engine · V · engine: epoll

vanilla is a minimalist, high-performance HTTP server written in V: multi-threaded, non-blocking epoll I/O, lock-free, copy-free, SO_REUSEPORT. Handlers are pure (request)->[]u8 returning raw response bytes. JSON is built in a single allocation with precomputed prefixes (no per-request reflection); json-comp gzips on Accept-Encoding; json-tls terminates TLS 1.3 (Mbed TLS 4) on :8081 with ALPN http/1.1, reusing the same allocation-free /json serializer; static-tls serves the 20 /static files on :8081 through vanilla's static_assets (br/gzip negotiation; snapshots re-checked against the disk, so a replaced file is served at once), sending bodies of 16 KiB or more with sendfile(2) over kTLS; fortunes renders the DB rows + a runtime row with HTML escaping; async-db/crud/fortunes use the native async pg_async driver with per-worker pipelined pools. Pinned V master (built from source, bootstrap pinned). async parks each /delay/{ms} on a one-shot timerfd from a per-worker free-list and answers only once it reports an expiration; 8gbit echoes the POST body on the :8081 TLS listener (Content-Length or chunked, per-worker dechunk buffer); production-stack's /api cache-aside (X-Cache MISS/HIT, 1 s items / 30 s users TTL, invalidated on write) runs in-process — no Redis required. The h2c profiles run on an h2c-only epoll listener on :8082 (an HTTP/1.1 request there gets 505): the connection preface (PRI *) parses as an ordinary request, the handler hands the connection to vanilla's http2 module (core.queue_takeover) and appends the server SETTINGS, and every later burst goes to the RFC 9113 machine, which surfaces a request only when it is complete; /json reuses the same prefixes and body writer. unary-grpc takes the same preface on :8080 and answers GetSum as HEADERS, the SumReply as DATA, then grpc-status 0 as trailers. The echo-ws profiles share the :8080 engine: GET /ws validates the RFC 6455 upgrade, appends the 101 and hands the connection over (core.queue_takeover), after which every readable burst goes to a ConnHandler that walks the frames (echo, ping/pong, close) instead of the HTTP/1.1 parser; a pipelined burst is drained in one call and coalesced into one write, and the accept key is computed on the stack, so an upgrade allocates nothing. One worker per CPU of the container's cpuset.

• Official repository
• Benchmark implementation
• All V entries, compared
• Open the leaderboard

Achievements

🥇 1 Gold · 🥈 1 Silver · 🥉 3 Bronze. Top three of a field, taken in this entry's own league: the family composite, the same composite among entries written in the same language, and each test profile it is scored on. Every field is the one the badges publish, so a medal and a badge always say the same thing. How medals are awarded.

Composite rank

Each profile of a family is worth 100 to the entry that leads it, and the composite is the sum over the family, less 2.5% for each of routing, middleware, request and response the entry does not do for you - its completeness factor, which the WebSocket and gRPC families do not carry. The field is this entry's own league: engines and reverse proxies are scored apart from frameworks. How it works.

Every result

Alpha Round, 35 runs. Requests per second is the best of three; latency, CPU and memory come from that run.

Compared with

The V entries around vanilla-epoll on the HTTP/1.1 composite, and the one leading them. The last column shows every profile side by side.

Compare vanilla-epoll with any V entry · Compare vanilla-epoll with any entry, in any language · Every V entry, ranked

Results updated 2026-10-14 · How the benchmark is run · The machine · Add or fix an entry