I love this kind of projects which people receive with much skepticism, but after some years will bring interesting improvements to us.
Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
81–85 of 85 posts
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#82Earlier quoted context omitted.
You are incorrect, modern clients are fast and requests typically reside in buffers by the time event driven webservers decide to read them. Nginx had parsing with state retention because of the simple idea to handle large amounts of slow clients, which was a problem back when nginx was born. As it turned out later it didn't help with malicious clients at all, because costs to retain clients' connections and get and…
> You are incorrect, modern clients are fast and requests typically reside in buffers by the time event driven webservers decide to read them. Hmm. Not sure if that's universally true. I've heard that in some cases HTTP requests can be quite large due to having several cookies, long strings of Accept: garbage, etc. My impression was that this could make them not only exceed the MSS (thus be in multiple packets) but a…
> in some cases HTTP requests can be quite large
Sure. I might have slightly overgeneralized some things to illustrate the point.
> equivalent on Linux
TCP_DEFER_ACCEPT is something similar on Linux
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#83Earlier quoted context omitted.
Omitting one feature might not but things add up. Compare HTTP parsing in nginx with this one and you'll notice how much more rigor nginx is about it. Parsing transfer-encoding by itself is costly for example, and nginx does it whether you ask for it or not because it has to populate the structure after all. Just because features are not used doesn't mean they don't have a cost. Features drives you to make design cho…
It's perfectly fair because those using h2o won't be using any of those features (because they can't). So the fact that nginx provides these unwanted features is irrelevant. And if you needed those features, then you wouldn't care if h2o is faster or not.
It's not fair because you are not comparing apples to apples. I can write a poll loop that accepts and sends back http responses and call it a webserver.
h2o doesn't even use sendfile(2) which means file data is read and copied to the userland just to be copied back to the kernel to send it to the socket buffer. Turn this on in nginx and you'll see a significant performance improvement.
nginx can be tuned a lot to improve performance and the author didn't bother doing that.
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#84Earlier quoted context omitted.
> You are incorrect, modern clients are fast and requests typically reside in buffers by the time event driven webservers decide to read them. Hmm. Not sure if that's universally true. I've heard that in some cases HTTP requests can be quite large due to having several cookies, long strings of Accept: garbage, etc. My impression was that this could make them not only exceed the MSS (thus be in multiple packets) but a…
> in some cases HTTP requests can be quite large Sure. I might have slightly overgeneralized some things to illustrate the point. > equivalent on Linux TCP_DEFER_ACCEPT is something similar on Linux
> TCP_DEFER_ACCEPT is something similar on Linux
Not similar enough. In the case I was describing, there are some bytes to read but not a full HTTP request. TCP_DEFER_ACCEPT prevents accept() from returning until there are some bytes to read. That doesn't help.
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#85Interesting article. And congratulations for the release! Sorry this is a bit off-topic (and doesn't apply to H2O as it's been in the works for a while looking at the commits), but I wonder, today, with a language like Rust (1.0 is at the door [1]), as performant as its safe C equivalent but modern and safe by design (and with an escape hatch to C/C++ if needed), what would be the advantages of starting a long term p…
Note: Rust 1.0 does not mean feature complete, it means backwards compatible. A lot of the builtin libraries and features (eg compiler plugins) will not be available for use in 1.0 Rust (only in the nightlies)
1.0 Rust gives an option for people wanting to use it in production, and as far as comparing it with C goes it has a lot more functionality, but there is still a long way to go before the "stable" Rust has all the awesomeness that Rust nightlies have right now.