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.
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'd wager that in the next 96 hours, with a LLM, someone could create a translator that would 'pack' a nginx or caddy configuration file into the relevant code that zeroserve could use. Or even more simply, just pickup all the Ingress manifests in a kubernetes cluster and rebuild the pack. The point being, the interface between the tool and the configuration is just another API, system operators are already describing the state of the system at higher level constructs, and the specific bytes that make up the configuration are an artifact of that.
I suspect it's worth exploring if that will change as AI is allowing more and more "human words -> machine effect", which may be more ergonomic for the AIs. It could take a long time for that kind of shift to become clearly a good idea since the AI can make either work.
Why are you so eager to credit LLMS.. Just because they wrote the article with the help of an LLM doesnt mean they're out here having LLMs do the experiments for them.
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.
Depends on the domain. There's a bunch of sciences using large datasets served up efficiently using static file formats, e.g., https://zarr.dev/ and https://parquet.apache.org/
I did last week (converted ghost to static) and was half wondering if some self contained binary wouldn't be faster so I feel like this was made for me, but I accept I'm not the typical user
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.
Hi, author here - a few critical pieces of this, like async-ebpf, were written long before those coding agents were released. I use AI assistance a lot when creating zeroserve itself, but I manually check AI output and take responsibility for it :)
if the point is to avoid the lua-issue on nginx, how do you expect people will implement things like geoip, request content match post ssl termination, etc?
Small static file (174 B) - the bread and butter of static sites:
server req/s p99
zeroserve 36,681 5.4 ms
nginx 31,226 7.8 ms
Caddy 12,830 22 ms
zeroserve serves small files about 17% faster than nginx on a single core, with a tighter tail. HTML pages, small JSON, CSS - this is the case zeroserve is tuned for.
Large static file (100 KB):
server req/s throughput p99
zeroserve 8,000 782 MB/s 22 ms
nginx 7,600 773 MB/s 28 ms
Caddy 6,084 590 MB/s 44 ms
I'd go with a more storied project that's been audited, battle tested, hardened etc than this upstart. There's not enough improvement to justify the risk.
The problem with pasting LLM output is that no human with sound mind and body would waste their finite time on this Earth informing you that small static files are "the bread and butter of static sites".
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!
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.
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'd wager that in the next 96 hours, with a LLM, someone could create a translator that would 'pack' a nginx or caddy configuration file into the relevant code that zeroserve could use. Or even more simply, just pickup all the Ingress manifests in a kubernetes cluster and rebuild the pack. The point being, the interface between the tool and the configuration is just another API, system operators are already describing the state of the system at higher level constructs, and the specific bytes that make up the configuration are an artifact of that.
What about abstracting the complexity and achieving "config file" configuration with macros?
I suspect it's worth exploring if that will change as AI is allowing more and more "human words -> machine effect", which may be more ergonomic for the AIs. It could take a long time for that kind of shift to become clearly a good idea since the AI can make either work.
Why are you so eager to credit LLMS.. Just because they wrote the article with the help of an LLM doesnt mean they're out here having LLMs do the experiments for them.
because it makes it easy to create/reverse engineer projects/explore on a whim without putting up a lot of time
LLM enables a lot of good output if you know what you are doing
Bayesian inference suggests otherwise.
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.
Hi, thanks!
Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)
Cool idea, but I don't think you should focus on static files. People rarely spin up a server for that these days.
Depends on the domain. There's a bunch of sciences using large datasets served up efficiently using static file formats, e.g., https://zarr.dev/ and https://parquet.apache.org/
I did last week (converted ghost to static) and was half wondering if some self contained binary wouldn't be faster so I feel like this was made for me, but I accept I'm not the typical user
You just helped to dredge up a memory, which brought me back to this fascinating project:
https://redbean.dev
If this piques your interest, make sure to check out the portable C library used to create it, which is also fascinating:
https://github.com/jart/cosmopolitan
I did it yesterday.
Why a tarball?
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.
Hi, author here - a few critical pieces of this, like async-ebpf, were written long before those coding agents were released. I use AI assistance a lot when creating zeroserve itself, but I manually check AI output and take responsibility for it :)
Happy to hear, I hope the tool can prove itself to a wider audience then.
if the point is to avoid the lua-issue on nginx, how do you expect people will implement things like geoip, request content match post ssl termination, etc?
Given the benchmarks:
Small static file (174 B) - the bread and butter of static sites:
server req/s p99
zeroserve 36,681 5.4 ms
nginx 31,226 7.8 ms
Caddy 12,830 22 ms
zeroserve serves small files about 17% faster than nginx on a single core, with a tighter tail. HTML pages, small JSON, CSS - this is the case zeroserve is tuned for.
Large static file (100 KB):
server req/s throughput p99
zeroserve 8,000 782 MB/s 22 ms
nginx 7,600 773 MB/s 28 ms
Caddy 6,084 590 MB/s 44 ms
I'd go with a more storied project that's been audited, battle tested, hardened etc than this upstart. There's not enough improvement to justify the risk.
The problem with pasting LLM output is that no human with sound mind and body would waste their finite time on this Earth informing you that small static files are "the bread and butter of static sites".
I'm convinced that LLMs somehow settled on the middle manager as the exemplar of human cognition that it tries its best to emulate.
I could totally see "Small static files are the bread and butter of static sites" appearing in some pointless deck on a Zoom call.