The biggest result of my research this year: HTTP server benchmarks are pretty much just a benchmark on how good the "Date:" header implementation is.

@PeterCxy@comfy.social In other words, you can greatly boost static-page performance just by removing "Date:" from a HTTP server?!

@niconiconi@mk.absturztau.be If the original date and/or its formatting implementation is horrible, that is. Most HTTP server implementations on the top of the rankings generally either hard-code that header or use simple template-based formatting.

@niconiconi@mk.absturztau.be The most difference in terms of throughput I have seen from adding/removing the Date header (or using a hard-coded / cached / non-real-time value) is like 20% - 30%.

@PeterCxy @niconiconi I don't understand

@robookwus@fosstodon.org @niconiconi@mk.absturztau.be because when all you have is a simple static web server, and the static web page itself is in memory (or on disk but cached into memory, which is common), the only real complicated task to do is fetching the current date, formatting it and then populating the Date header. These benchmarks of HTTP servers, especially when they only expect you to serve a static page, end up mostly just stressing this Date header routine.

@PeterCxy
I'm confused why anyone is regenerating Date field value for every request. It's eminently cacheable (for the next second), and some sort of RCU setup (or optimistic concurrency control, but that's more expensive on average) with a periodic task that updates the value should work well, and not require optimizing date printing.

@niconiconi @robookwus

@robryk@qoto.org @niconiconi@mk.absturztau.be @robookwus@fosstodon.org You have just explained why more than half of the HTTP server implementations are horribly slow :)

@PeterCxy

What I'm confused about is anyone who actually tries to write optimized Date generator (you implied that happens?). This is a case when someone clearly cared about making it fast, and did the more complicated thing to do so. @niconiconi @robookwus