The death of the techempower web server benchmarks means new ones like this one no longer have the chance to prove themselves.

Edit: it seems I'm just falling behind and the new hotness is https://www.http-arena.com/leaderboard/. Good luck!

I love seeing stuff like this that would probably not exist if not for LLMs making exploring these kinds of ideas relatively cheap and quick to do.

My takeaway from this though is that nginx is pretty impressive on its own. Also this stuck out:

It's meant to be an alternative to nginx and Caddy, and the design bet is about configuration. Those servers give you a declarative config language - location blocks, rewrite rules, map directives, try_files - and then, once the declarative language hits its limits, an optional scripting runtime bolted on the side (Lua, or Caddy's plugins). Behavior ends up split across two layers: directives that quietly grow their own control flow, plus scripts that run somewhere in the request lifecycle you have to keep in your head.

I think the bet is misplaced - people prefer configuration over code and long have. The built-ins meet enough peoples needs entirely and they don't need to write C code.

I like the idea.

I think I'd feel more comfortable if I could drop an .rs file into the eBPF dir instead of a .c one. It's already a Rust project! :)

And for some reason I was expecting this to be a kernel-accelerated webserver - if that could be done safely using eBPF that would be amazing!

Also, single-threaded? Forking and sharing an incoming connection queue is basically trivial on Linux, that should be literally just a few lines, even with Rust. Use SO_REUSEPORT and the kernel will do the rest.

FWIW, if you're going to push for io_uring, you should also be pushing kTLS IMO, you'll drastically simplify your design if you can avoid pumping userspace SSL after the handshake.

I was just thinking about eBPF and I stumbled upon this, what a coincident!

Very interesting idea and thanks for the no bs benchmarks! I wonder if this architecture could be ported to webservers with dynamic content/logic, too.

Very cool! would be interesting to see about combining this with other bpf program types like xdp progs, or socket map attached programs to integrate L7 http features downward.

Cool idea, but I don't think you should focus on static files. People rarely spin up a server for that these days.

Looks good, nice features. But somehow the spark does not ignite on my side because it feels too artificial. I don't know if the metrics are faked, if the convenience functions actually work, if there is any proper hardening.

I can accept if stuff is vibe coded and has autogenerated README. But even the announcement blogpost is AI-generated, and I personally have zero data points to see if your understanding of software quality is the same as mine.

It's a weird world, if this would've been announced without any AI disclaimers some years earlier I would've eaten it up without a doubt. But right now if I see a fancy README with several good-looking command line parameters I immediately wonder if the README is hallucinated and the command line parameters actually exist.

OT, Another benchmarks showing Caddy not performing on par with Nginx. And the difference aren't so either, roughly 2.5x in small asset serving at nearly 3x latency. On normal 100KB static files it is 20% less throughput but most importantly nearly double the latency.

Unfortunately, Caddy seems to take less concern on this.

Zeroserve already beats Nginx in performance. Hopefully someday it would catch up to Caddy's features.

Why a tarball?

It’s an interesting new concept I like it.

The real question is developer commitment and community - the Caddy and Nginx people have worked constantly on supporting their products. It’s going to take a lot of focus and attention.

undefined

Is there a web server in eBPF though?

this looks amazing

[dead]

[flagged]