Mibbit uses a custom webserver... Instead of gzipping things on the fly, I decided to just look for a .gz version on the filesystem, and use that if it's there.
eg a request for 'index.html' looks for 'index.html' and 'index.html.gz'. If the gz is there it uses that and sets headers accordingly.
Works incredibly well, and the deploy scripts just gzip things when they're pushed out to production.
I don't know if this applies to your site or not, but if you have any dynamic http requests (non-cacheable) that approach doesn't work very well. You're much better off doing it on the fly with nginx as paul suggests; the impact on CPU is not noticeable even under very heavy load.
Yeah dynamic stuff is a whole different kettle of fish. The dynamic content on Mibbit is usually very small - maybe 100-200 bytes. The HTTP request headers are usually more (Which can't be compressed).
For Mibbit, I'd like to eventually do my own compression which will beat the socks off gzip, as it'll be session based rather than per request.
But yeah, I can see use cases where you're sending dynamic stuff which will benefit from gzip and where pre-caching on disk doesn't really make sense.
It handles 2,000 HTTP requests a second on a single 1.4GB VPS server, which I think is good. It'll likely go to 10k/s or more... probably until the bandwidth is saturated.
Writing an HTTP server is easy. But making one that handles long lived connections (10s of thousands), and scales well, doesn't eat memory, doesn't eat CPU, etc etc is harder.
Having said that, it's easy enough that I think it's often worth doing if the webserver is integral to your success (It is with Mibbit).
That's pretty impressive! How much memory does it need per connection? I think that's the primary metric I'd use to assess Cometworthiness (once all the basic stuff is taken care of, e.g. delivering 1000 outbound events per second takes the same amount of CPU regardless of whether there is only one outbound connection or 100 000 of them).
My main point was that it would be hard to tell if someone somewhere had an HTTP implementation that could handle 250 000 concurrent HTTP connections per 64MB of RAM while yours only handled, say, 5000 per 64MB. (I suspect the former number is achievable; I know the latter is.)
I can confirm from experience that writing an HTTP server that scales well without eating memory or CPU is dramatically harder than just writing an HTTP server. However, it's very easy to do better than apache-mpm-prefork. (No need, though; lighttpd and nginx should both do better at that, I have heard that perlbal does too, and I suspect from experience that twisted.web does as well, although I haven't measured it.)
eg a request for 'index.html' looks for 'index.html' and 'index.html.gz'. If the gz is there it uses that and sets headers accordingly.
Works incredibly well, and the deploy scripts just gzip things when they're pushed out to production.