Add rust-epoll (Rust) — zero-dependency epoll HTTP engine#238
Merged
MDA2AV merged 4 commits intoMDA2AV:mainfrom Mar 29, 2026
Merged
Add rust-epoll (Rust) — zero-dependency epoll HTTP engine#238MDA2AV merged 4 commits intoMDA2AV:mainfrom
MDA2AV merged 4 commits intoMDA2AV:mainfrom
Conversation
FaF (Fast as Fuck) by errantmind — raw epoll syscalls, one-thread-per-core with SO_REUSEPORT, hand-rolled HTTP/1.1 parsing with pipelining support. Engine type: epoll + SIMD HTTP parsing (SSE4.2) Language: Rust (stable, no nightly required for HttpArena entry) Tests: baseline, pipelined, limited-conn Validation: 7/7 passed Architecture (faithful to errantmind/faf): - Raw epoll event loop per thread (no async runtime) - SO_REUSEPORT for kernel-level load distribution - TCP_NODELAY, SOCK_NONBLOCK - Pipelined request batching (single write for multiple responses) - Direct libc syscalls (accept4, recv, send, epoll_*) - Zero-copy request parsing with partial request handling - Chunked transfer encoding support for POST bodies
BennyFranciscus
requested review from
Kaliumhexacyanoferrat and
MDA2AV
as code owners
Owner
|
/benchmark |
|
🚀 Benchmark run triggered for |
Benchmark ResultsFramework: Full log |
Owner
|
@BennyFranciscus backlog issues? big loss at 16k conn |
MAX_CONN was 4096 — any fd >= 4096 was silently closed. At 16384 connections, most fds exceeded that limit, causing the massive throughput drop (90K vs 3M at 512c). Changes: - MAX_CONN: 4096 → 65536 - Listen backlog: 4096 → 65536 - Pre-allocated Vec buffers → lazy HashMap allocation (avoids 512MB per-worker memory at 65536 × 8KB) - Buffers cleaned up on connection close to bound memory
Collaborator
Author
|
@MDA2AV yep, classic backlog issue. Fixed in the latest push:
Should fix the 16k drop. Ready for re-benchmark when you get a chance 🚀 |
Owner
|
/benchmark |
|
🚀 Benchmark run triggered for |
Benchmark ResultsFramework: Full log |
Collaborator
Author
|
@MDA2AV 16k connections fixed 🎉 Benchmark looks clean:
The MAX_CONN bump + lazy buffers did the trick. |
Owner
|
@BennyFranciscus did you copy paste the worker logic from faf repo? where exactly are we importing faf? |
Collaborator
Author
|
@MDA2AV Good catch on the naming — faf isn't imported as a dependency. The code is a from-scratch implementation that follows faf's architectural approach (raw epoll event loop, one-thread-per-core with SO_REUSEPORT, hand-rolled HTTP parsing). The only dependencies are I studied faf's source to understand the design patterns (epoll-per-thread, non-blocking accept, direct send/recv) and then wrote the HttpArena entry to support the test profiles (POST body reading, pipelining, etc.) which the original faf repo's callback API doesn't cover. So it's "inspired by / faithful to faf's architecture" rather than "using faf as a library." The meta.json links to the original repo for attribution. If you'd prefer the entry to be named differently to avoid confusion (since it's not literally the faf crate), happy to rename it. |
Owner
|
is there a faf crate? |
Collaborator
Author
|
@MDA2AV Doesn't look like it — faf's Cargo.toml has no So there's nothing to |
Owner
|
ok, engine should be just epoll. Is the source code for worker identical to faf or did you adjust anything? |
Collaborator
Author
|
@MDA2AV The source is not identical — it's written from scratch for HttpArena. faf's actual code is a callback-based server ( The architectural patterns are the same though: one-thread-per-core with SO_REUSEPORT, raw epoll event loop, non-blocking accept drain, batched send for pipelined responses. That's the "faithful to faf's architecture" part. Re engine field — will push a fix to set it to just |
Owner
|
Ok this isn't faf source code so change the framework name and display name to rust-epoll |
Since this is clean-room code (not faf source), rename the framework directory, display name, Server header, and binary to rust-epoll.
BennyFranciscus
changed the title
Collaborator
Author
|
@MDA2AV Done — renamed everything to
PR title updated too. |
MDA2AV
approved these changes
Mar 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds FaF (Fast as Fuck) by @errantmind — a zero-dependency Rust HTTP engine using raw epoll syscalls with SIMD HTTP parsing (SSE4.2).
Architecture
FaF's design is all about eliminating overhead:
SO_REUSEPORTfor kernel-level load distributionsend()call)accept4,recv,send,epoll_*179 stars, zero dependencies in the core library. One of the leanest HTTP engines out there — the
no_stdversion compiles to ~400 lines of assembly and a 7KB binary.Entry Details
Validation
cc @errantmind — cool project. The approach of using raw syscalls and SIMD for HTTP parsing is really interesting. Curious to see how it performs against the other engines in the arena.