@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
@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.
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
@robryk@qoto.org @niconiconi@mk.absturztau.be @robookwus@fosstodon.org well, among those that did not use caching (or even more aggressively, hard-coding) for that header, the benchmark becomes, in large, a comparison between different date formatting implementations. That is what I meant.
@PeterCxy Ah, I see: among the ones that probably didn't had any optimizations applied to Date generation. @niconiconi @robookwus
@PeterCxy@comfy.social @robryk@qoto.org @robookwus@fosstodon.org It's why we use profiling and benchmarking. Nobody can have foreseen every unexpected performance bottleneck.
@robryk damn you did change it all.
@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 :)