9 ms·

Zeroserve: A zero-config web server you can script with eBPF

272 points by losfair 3mo ago

opem 3mo ago
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.
z3ratul163071 3mo ago
this looks amazing
bflesch 3mo ago
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.
- gigatexal 3mo ago
  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.
  - tadfisher 3mo ago
    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".
    - antonvs 3mo ago
      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.
- losfair 3mo ago
  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 :)
  - iririririr 3mo ago
    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?
  - bflesch 3mo ago
    Happy to hear, I hope the tool can prove itself to a wider audience then.
  - rpdillon 3mo ago
    I'm of the school of thought that if a practicing/retired software engineer (i.e. someone I reasonably believe has experience writing software for "production") wrote it, I've got to show it's trash, rather than assume it's trash. "Innocent until proven guilty" and all that. But I'm in the rather luxurious position of mostly using open source, rather than maintaining it, so I understand that others come down differently on this topic. FWIW, I like the writeup and concept behind this. Very close to some passions of mine (like serving a website from a single-file archive).
- shevy-java 3mo ago
  > 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. Yeah, that is unfortunate. Recently there was this ffmpeg-wasm project. I tested it. It worked. But it was vibe-coded AI. I can't stand AI. Even if things work. I decided to stay in the oldschool era as much as possible. Clever people publish software. Clever people maintain software. They don't need AI. That's my niche. We may die out but I still prefer that. (Oh, and only if these clever people write documentation. Many clever people hate writing documentation. I decided a long time ago that if software comes without documentation, it is not worth my time, no matter how great that documentation is. This refers mostly to on-the-application side; I only rarely looked at the Linux documentation, but others stated that it is not too terrible either, so who knows.)
mmastrac 3mo ago
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.
- losfair 3mo ago
  Hi, thanks! Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)
  - opem 3mo ago
    I wonder how zs_reverse_proxy() + SO_REUSEPORT would perform
  - Woodi 3mo ago
    Pleas think before forking(). Do not follow Apache blindly... Code, as is today, looks [acording to benchmarks] better then nginx, except one case ! There is fcgi in, right ? So all that additional processes are already started in the backend. If benchmarks are real no need to complicate code before some industry adoption. Of course there can be a branch to check possibilities :) And forking is complicated and full of surprising traps. Even if they are somewhat "standard" historic Unix traps... Case study: Perl - better don't use fork there even if "threads" are in.
- tekacs 3mo ago
  I was curious for the same thing, so I quickly (with an agent) threw support for .rs scripts together on my fork: https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b3324e81640b932e04f2050b https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b... It does leave me wondering about other runtimes that could be used as the go-between though, because at the point of compiling Rust, an approach like Cloudflare's Pingora (https://github.com/cloudflare/pingora https://github.com/cloudflare/pingora) which I've tried using before... in _theory_ should be a 'nicer' solution - just historically awkward when I've tried using it the way that I'd have liked. Wish it were more library-shaped!
jarym 3mo ago
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.
- lelandbatey 3mo ago
  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.
- high_priest 3mo ago
  What about abstracting the complexity and achieving "config file" configuration with macros?
- ai_fry_ur_brain 3mo ago
  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.
  - zuzululu 3mo ago
    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
mmarian 3mo ago
Cool idea, but I don't think you should focus on static files. People rarely spin up a server for that these days.
- dwedge 3mo ago
  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
  - arcanemachiner 3mo ago
    You just helped to dredge up a memory, which brought me back to this fascinating project: https://redbean.dev 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 https://github.com/jart/cosmopolitan
    - rpdillon 3mo ago
      These projects are fascinating, and I referenced them in a nearby comment about static hosting from archives. I need to try the latest versions to see how they work at higher scale (more data in the archive).
  - mmarian 3mo ago
    Why not let Clouflare/GitHub/etc do it for you? Free, and you don't have to worry about security and availability.
    - dwedge 3mo ago
      Because handing off control of a static site to a company that already controls XX% of the Internet for "security" goes against everything I believe in. And availability, cloudflare and github?
- lmc 3mo ago
Lapsa 3mo ago
[dead]
rashkov 3mo ago
Why a tarball?
- Terretta 3mo ago
  Well, according to first paragraph of the section titled "One tarball, served in place": The whole site is a single tar file. zeroserve indexes it on load - building a path -> byte-range map - and then serves files by issuing byte-range reads against the tarball itself. Nothing is ever unpacked to disk. The site lives entirely in that one file, so there's no document root for a stray location rule to expose, and a deploy is a single atomic file swap. OTOH, that could be an LLM justification, since the copy is littered with -isms like "the right shape" or "the surface is broad".
  - rashkov 3mo ago
    Thanks, I missed that during my read of it
- cwillu 3mo ago
  It's a simple format easily suitable for accessing resources by byte ranges, that everyone has tooling for, and which _doesn't_ compress things.
  - rpdillon 3mo ago
    It would be interesting to extend it to zip, which is what redbean/greenbean use to serve static assets. Back in school, I worked on a project called Velox, with a partner - the idea was to take a bz2-compressed dump of the giant XML export of wikipedia, and write a program to serve that copy of wikipedia from disk (this was in 2008-2010? in my master's program, so before Kiwix and the amazing zim dumps they produce). My partner worked on the UI and indexing, and I was focusing on how to parse the bz2 compression format to locate article boundaries in the (giant) XML dump that Wikipedia provides. I ended up putting a lot of time into it because it was a bunch of fun. Writing this just sent me back to the presentation I made. The slide I wrote back then said: > Significant original work went into creation of archive access. The Apache BZip2 library that is part of Ant was used as a basis for archive access. > Modified to support random access to a given byte/bit offset pair within the compressed data stream (BZip2 is not a byte-aligned format) > Extended to index all BZip2 block positions, allowing Java-based pseudo-random access to BZip2 compressed data > Extended to map article IDs to block numbers for constant-time article retrieval, even in BZip2 archives exceeding 5GB in size > Current article retrieval times are ~2 seconds. This is back when the archive was ~7GB IIRC. My Kiwix dumps today are ~120GB, but that includes images. This is the link to the presentation in Google Slides that we wrote back in 2008 or so. The version history shows 2013, but I think some kind of import/conversion happened around that time. https://docs.google.com/presentation/d/e/2PACX-1vTfrxEqvHbd0k_x6B_hDI2NVx8AVCNL5QCK0rVWU5YK4d0zstG0TJuktr22tpeFH5K-lwJcZsFwMBox/pub https://docs.google.com/presentation/d/e/2PACX-1vTfrxEqvHbd0...
password4321 3mo ago
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/ https://www.http-arena.com/leaderboard/. Good luck!
- winter_blue 3mo ago
  What do you mean it's dead? It's up at: https://www.techempower.com/benchmarks/#section=data-r23 https://www.techempower.com/benchmarks/#section=data-r23 with the last benchmark having been in February 2025, but they don't run their benchmarks that often, only once a year or less as its rounds history indicates.
  - password4321 3mo ago
    Maybe we're both part of today's lucky 10,000 (xkcd#1053)? Sunsetting the Techempower Framework Benchmarks https://news.ycombinator.com/item?id=47497763 https://news.ycombinator.com/item?id=47497763
- dakolli 3mo ago
  LLM UI/UX is so bad. Like how hard is it to put a weekends effort into UX for something like this.
  - j_clark 3mo ago
    Spot on. It’s painful to see someone build something technically impressive only to do a disservice to their own effort with a bad interface.
  - MDA2AV 3mo ago
    Unfortunately I might have to agree that the UI/UX isn't the strong point, as expected of a website built by a firmware developer using AI tools' help, I would appreciate any feedback on how to improve it though, regardless, the tough part on a project like this is what is invisible to the eye, stable hardware/harness and reviewing PRs in 20 different languages/technologies to keep the leaderboard competitive.
razighter777 3mo ago
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.
deleted 3mo ago
[deleted]
andrewstuart 3mo ago
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.
MagicMoonlight 3mo ago
[flagged]
- jhack 3mo ago
  You should post the results of your source code audit.
- rpdillon 3mo ago
  > All you did was ask the slop generator to make it. Is this founded? I know it's popular to trash every new project that's built with AI in the pipeline somewhere, but there's a big difference between a project built by someone with years of experience writing software and some vibing a repo with Claude. Isn't it worth distinguishing between the two? In the case of this project: a non-technical person couldn't even conceive of this product. So I think some kind of evidence should be presented before we say things like "Is it a logical design? Who knows." EDIT: Taking a look at the source, it looks very good. https://github.com/losfair/zeroserve/blob/main/src/server.rs https://github.com/losfair/zeroserve/blob/main/src/server.rs is an important part of the functionality, and it looks like it had a fair amount of attention paid to the implementation, including multiple refactors.
lost9 3mo ago
Is there a web server in eBPF though?
ksec 3mo ago
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.
- b112 3mo ago
  Well there's less concern because of how no one cares about latency these days. You don't serve up a bazillion js files and care about latency. You also don't serve up files from all over the web (fonts from google, jquery or whatever from their site) unless you don't care about having control over your own latency. A static HTML page renders in under 20ms for me these days, if the site is near. Some of these pages with immense blather of js take > 10 seconds to fully download and render. So... in that world, who cares if it's 5 seconds or 6 seconds?

272 points by losfair 3mo ago

opem 3mo ago

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.

z3ratul163071 3mo ago

this looks amazing

bflesch 3mo ago

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.

gigatexal 3mo ago
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.
- tadfisher 3mo ago
  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".
  - antonvs 3mo ago
    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.
losfair 3mo ago
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 :)
- iririririr 3mo ago
  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?
- bflesch 3mo ago
  Happy to hear, I hope the tool can prove itself to a wider audience then.
- rpdillon 3mo ago
  I'm of the school of thought that if a practicing/retired software engineer (i.e. someone I reasonably believe has experience writing software for "production") wrote it, I've got to show it's trash, rather than assume it's trash. "Innocent until proven guilty" and all that. But I'm in the rather luxurious position of mostly using open source, rather than maintaining it, so I understand that others come down differently on this topic. FWIW, I like the writeup and concept behind this. Very close to some passions of mine (like serving a website from a single-file archive).
shevy-java 3mo ago
> 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. Yeah, that is unfortunate. Recently there was this ffmpeg-wasm project. I tested it. It worked. But it was vibe-coded AI. I can't stand AI. Even if things work. I decided to stay in the oldschool era as much as possible. Clever people publish software. Clever people maintain software. They don't need AI. That's my niche. We may die out but I still prefer that. (Oh, and only if these clever people write documentation. Many clever people hate writing documentation. I decided a long time ago that if software comes without documentation, it is not worth my time, no matter how great that documentation is. This refers mostly to on-the-application side; I only rarely looked at the Linux documentation, but others stated that it is not too terrible either, so who knows.)

mmastrac 3mo ago

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.

losfair 3mo ago
Hi, thanks! Will implement forking + SO_REUSEPORT. I've been using nftables for things like this so haven't needed it for myself yet :)
- opem 3mo ago
  I wonder how zs_reverse_proxy() + SO_REUSEPORT would perform
- Woodi 3mo ago
  Pleas think before forking(). Do not follow Apache blindly... Code, as is today, looks [acording to benchmarks] better then nginx, except one case ! There is fcgi in, right ? So all that additional processes are already started in the backend. If benchmarks are real no need to complicate code before some industry adoption. Of course there can be a branch to check possibilities :) And forking is complicated and full of surprising traps. Even if they are somewhat "standard" historic Unix traps... Case study: Perl - better don't use fork there even if "threads" are in.
tekacs 3mo ago
I was curious for the same thing, so I quickly (with an agent) threw support for .rs scripts together on my fork: https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b3324e81640b932e04f2050b https://github.com/tekacs/zeroserve/commit/b33f261615d20d55b... It does leave me wondering about other runtimes that could be used as the go-between though, because at the point of compiling Rust, an approach like Cloudflare's Pingora (https://github.com/cloudflare/pingora https://github.com/cloudflare/pingora) which I've tried using before... in _theory_ should be a 'nicer' solution - just historically awkward when I've tried using it the way that I'd have liked. Wish it were more library-shaped!

jarym 3mo ago

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.

lelandbatey 3mo ago
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.
high_priest 3mo ago
What about abstracting the complexity and achieving "config file" configuration with macros?
ai_fry_ur_brain 3mo ago
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.
- zuzululu 3mo ago
  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

mmarian 3mo ago

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

dwedge 3mo ago
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
- arcanemachiner 3mo ago
  You just helped to dredge up a memory, which brought me back to this fascinating project: https://redbean.dev 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 https://github.com/jart/cosmopolitan
  - rpdillon 3mo ago
    These projects are fascinating, and I referenced them in a nearby comment about static hosting from archives. I need to try the latest versions to see how they work at higher scale (more data in the archive).
- mmarian 3mo ago
  Why not let Clouflare/GitHub/etc do it for you? Free, and you don't have to worry about security and availability.
  - dwedge 3mo ago
    Because handing off control of a static site to a company that already controls XX% of the Internet for "security" goes against everything I believe in. And availability, cloudflare and github?
lmc 3mo ago

Lapsa 3mo ago

[dead]

rashkov 3mo ago

Why a tarball?

Terretta 3mo ago
Well, according to first paragraph of the section titled "One tarball, served in place": The whole site is a single tar file. zeroserve indexes it on load - building a path -> byte-range map - and then serves files by issuing byte-range reads against the tarball itself. Nothing is ever unpacked to disk. The site lives entirely in that one file, so there's no document root for a stray location rule to expose, and a deploy is a single atomic file swap. OTOH, that could be an LLM justification, since the copy is littered with -isms like "the right shape" or "the surface is broad".
- rashkov 3mo ago
  Thanks, I missed that during my read of it
cwillu 3mo ago
It's a simple format easily suitable for accessing resources by byte ranges, that everyone has tooling for, and which _doesn't_ compress things.
- rpdillon 3mo ago
  It would be interesting to extend it to zip, which is what redbean/greenbean use to serve static assets. Back in school, I worked on a project called Velox, with a partner - the idea was to take a bz2-compressed dump of the giant XML export of wikipedia, and write a program to serve that copy of wikipedia from disk (this was in 2008-2010? in my master's program, so before Kiwix and the amazing zim dumps they produce). My partner worked on the UI and indexing, and I was focusing on how to parse the bz2 compression format to locate article boundaries in the (giant) XML dump that Wikipedia provides. I ended up putting a lot of time into it because it was a bunch of fun. Writing this just sent me back to the presentation I made. The slide I wrote back then said: > Significant original work went into creation of archive access. The Apache BZip2 library that is part of Ant was used as a basis for archive access. > Modified to support random access to a given byte/bit offset pair within the compressed data stream (BZip2 is not a byte-aligned format) > Extended to index all BZip2 block positions, allowing Java-based pseudo-random access to BZip2 compressed data > Extended to map article IDs to block numbers for constant-time article retrieval, even in BZip2 archives exceeding 5GB in size > Current article retrieval times are ~2 seconds. This is back when the archive was ~7GB IIRC. My Kiwix dumps today are ~120GB, but that includes images. This is the link to the presentation in Google Slides that we wrote back in 2008 or so. The version history shows 2013, but I think some kind of import/conversion happened around that time. https://docs.google.com/presentation/d/e/2PACX-1vTfrxEqvHbd0k_x6B_hDI2NVx8AVCNL5QCK0rVWU5YK4d0zstG0TJuktr22tpeFH5K-lwJcZsFwMBox/pub https://docs.google.com/presentation/d/e/2PACX-1vTfrxEqvHbd0...

password4321 3mo ago

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/ https://www.http-arena.com/leaderboard/. Good luck!

winter_blue 3mo ago
What do you mean it's dead? It's up at: https://www.techempower.com/benchmarks/#section=data-r23 https://www.techempower.com/benchmarks/#section=data-r23 with the last benchmark having been in February 2025, but they don't run their benchmarks that often, only once a year or less as its rounds history indicates.
- password4321 3mo ago
  Maybe we're both part of today's lucky 10,000 (xkcd#1053)? Sunsetting the Techempower Framework Benchmarks https://news.ycombinator.com/item?id=47497763 https://news.ycombinator.com/item?id=47497763
dakolli 3mo ago
LLM UI/UX is so bad. Like how hard is it to put a weekends effort into UX for something like this.
- j_clark 3mo ago
  Spot on. It’s painful to see someone build something technically impressive only to do a disservice to their own effort with a bad interface.
- MDA2AV 3mo ago
  Unfortunately I might have to agree that the UI/UX isn't the strong point, as expected of a website built by a firmware developer using AI tools' help, I would appreciate any feedback on how to improve it though, regardless, the tough part on a project like this is what is invisible to the eye, stable hardware/harness and reviewing PRs in 20 different languages/technologies to keep the leaderboard competitive.

razighter777 3mo ago

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.

deleted 3mo ago

[deleted]

andrewstuart 3mo ago

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.

MagicMoonlight 3mo ago

[flagged]

jhack 3mo ago
You should post the results of your source code audit.
rpdillon 3mo ago
> All you did was ask the slop generator to make it. Is this founded? I know it's popular to trash every new project that's built with AI in the pipeline somewhere, but there's a big difference between a project built by someone with years of experience writing software and some vibing a repo with Claude. Isn't it worth distinguishing between the two? In the case of this project: a non-technical person couldn't even conceive of this product. So I think some kind of evidence should be presented before we say things like "Is it a logical design? Who knows." EDIT: Taking a look at the source, it looks very good. https://github.com/losfair/zeroserve/blob/main/src/server.rs https://github.com/losfair/zeroserve/blob/main/src/server.rs is an important part of the functionality, and it looks like it had a fair amount of attention paid to the implementation, including multiple refactors.

lost9 3mo ago

Is there a web server in eBPF though?

ksec 3mo ago

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.

b112 3mo ago
Well there's less concern because of how no one cares about latency these days. You don't serve up a bazillion js files and care about latency. You also don't serve up files from all over the web (fonts from google, jquery or whatever from their site) unless you don't care about having control over your own latency. A static HTML page renders in under 20ms for me these days, if the site is near. Some of these pages with immense blather of js take > 10 seconds to fully download and render. So... in that world, who cares if it's 5 seconds or 6 seconds?