Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

blog.kazuhooku.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#61

Post by scottlamb »

halayli wrote: post #36

This doesn't look like a complete HTTP server, comparing it with nginx is not fair. . It's missing content-encoding handling on the receiving side . No http continue support . No regex routing support . No header rewrites to name a few.

> This doesn't look like a complete HTTP server, comparing it with nginx is not fair.

It's certainly not full-featured, but I don't think any of the omissions you mentioned should invalidate a performance comparison. I'd expect them to have little cost when not used, and I assume he's not using them for nginx in these tests.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#62

Post by jaytaylor »

moe wrote: post #58
sparkzilla wrote: post #55

Earlier quoted context omitted.

You may be a bit off with your calculation. Wikipedia uses 15,000 cpus on 750 hosts. http://ganglia.wikimedia.org/latest/

You may be a bit off with your calculation Where? Wikipedia uses 15,000 cpus on 750 hosts. These are not all webservers. Also, even though they could run their load on a fraction of the hardware it would probably not make a lot of sense to optimize for that, as the potential cost savings are relatively small (servers are cheap).

The costs incurred for a system compromised of 750 hosts or 15,000 CPUs are most certainly nontrivial.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#63

Post by scottlamb »

I'm skeptical of the performance numbers. First, like others here I don't believe nginx's performance will be a bottleneck for HTTP/2. Beyond that, I suspect there are cases in which this code is much worse than nginx.

Here's one. Look at the example request loop on " rel="nofollow">https://github.com/h2o/picohttpparser/>. It reads from a socket, appending to an initially-empty buffer. Then it tries to parse the buffer contents as an HTTP request. If the request is incomplete, the loop repeats. (h2o's lib/http1.c:handle_incoming_request appears to do the same thing.)

In particular, phr_parse_request doesn't retain any state between attempts. Each time, it goes through the whole buffer. In the degenerate case in which a client sends a large (n-byte) request one byte at a byte, it uses O(n^2) CPU for parsing. That extreme should be rare when clients are not malicious, but the benchmark is probably testing the other extreme where all requests are in a single read. Typical conditions are probably somewhere between.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#65

Post by moe »

jaytaylor wrote: post #62
moe wrote: post #58

Earlier quoted context omitted.

You may be a bit off with your calculation Where? Wikipedia uses 15,000 cpus on 750 hosts. These are not all webservers. Also, even though they could run their load on a fraction of the hardware it would probably not make a lot of sense to optimize for that, as the potential cost savings are relatively small (servers are cheap).

The costs incurred for a system compromised of 750 hosts or 15,000 CPUs are most certainly nontrivial.

First off, 750 hosts don't have 15k CPUs. The ganglia metric likely refers to cores and doesn't account for hyperthreading.

And, again, 750 hosts is not too bad for an operation the size of Wikipedia.

A running server doesn't cost much in the grand scheme of things. You can infer that from the fact that ISPs will rent you one for under $30/mo and still make a profit on you.

Consequently the potential savings may not be trivial, but they're hardly big enough to justify tying up large parts of the team in an effort to squeeze out the last x%.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#67

Post by xorcist »

meowface wrote: post #41
xorcist wrote: post #9

Earlier quoted context omitted.

nginx' configuration format leaves a lot to be desired, as evidenced by the (former, hopefully) widespread use of exploitable php calls. There are also if directives in there, but they don't really work they way you think. You really need a deep understanding of its parsing rules in order to do anything remotely complicated with it. It's certainly possible to do better. (Please don't mention Apache here and its steam…

>nginx' configuration format leaves a lot to be desired, as evidenced by the (former, hopefully) widespread use of exploitable php calls. This has nothing to do with nginx's config format at all. It's simply a vulnerability in FastCGI for PHP and the way PHP file paths are passed.

It's a well documented feature that has existed since always. The vulnerability arises because the obvious way to configure this handler in nginx is to write regexps. You could just as well have handed the user a loaded gun pointed at their foot.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#68

Post by halayli »

scottlamb wrote: post #61
halayli wrote: post #36

This doesn't look like a complete HTTP server, comparing it with nginx is not fair. . It's missing content-encoding handling on the receiving side . No http continue support . No regex routing support . No header rewrites to name a few.

> This doesn't look like a complete HTTP server, comparing it with nginx is not fair. It's certainly not full-featured, but I don't think any of the omissions you mentioned should invalidate a performance comparison. I'd expect them to have little cost when not used, and I assume he's not using them for nginx in these tests.

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 choices that can affect the overall performance otherwise the feature cannot be implemented. Adding more code to your program might trigger a different code layout which can affect memory cache, and branch prediction.

It's not fair to blindly compare webserver performances without knowing the bottlenecks of each and how the faster webserver overcame those bottlenecks.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#69

Post by coldtea »

rakoo wrote: post #31
coldtea wrote: post #24

Earlier quoted context omitted.

Rust is not even 1.0. And even if it was, it would take 3-5 years until it gets any decent adoption (if that happens, which remains to be seen). It doesn't even have Go level adoption yet, and Go's adoption is not something to write home about either. C, people know very well, has tons of tooling, plays well in all platforms and has all the libraries in the world available for it.

> Go's adoption is not something to write home about either. I wouldn't say so... Go may not be as widespread as other older languages, but the speed at which it's taking over new developments (and sometimes re-writes) can't be glossed over that easily. Regarding GP's comment, I believe the number 1 argument why that project is started in C is performance. Even nginx, which is also written in C, can't match H2O's spe…

>I wouldn't say so... Go may not be as widespread as other older languages, but the speed at which it's taking over new developments (and sometimes re-writes) can't be glossed over that easily.

It has a decent following for a new-ish (5 years) language, but the HN echo-chamber makes it seem ever larger than it actually is.

In the general industry it's nearly a statistical error, especially in the enterprise.

Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015

#70

Post by rgbrenner »

halayli wrote: post #68
scottlamb wrote: post #61

Earlier quoted context omitted.

> This doesn't look like a complete HTTP server, comparing it with nginx is not fair. It's certainly not full-featured, but I don't think any of the omissions you mentioned should invalidate a performance comparison. I'd expect them to have little cost when not used, and I assume he's not using them for nginx in these tests.

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.

Post reply on HN