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

71–80 of 85 posts

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

#71

Post by makomk »

meowface wrote: post #42
lonnyk wrote: post #38

Earlier quoted context omitted.

> as evidenced by the (former, hopefully) widespread use of exploitable php calls Could someone elaborate on what this is referring to?

Read through https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...

That's not really nginx's fault, its behaviour is quite sensible. The main problem is that PHP does some poorly-documented magic behind the scenes[1] that modifies the information nginx gives it in a way that causes security issues. The solution is not to do that; if you really need the path-splitting functionality that cgi.fix_pathinfo provides, it's better and safer to set fastcgi_split_path_info in the nginx configuration instead.

[1] http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo - the docs on cgi.fix_pathinfo don't mention that it affects which PHP file gets executed at all.

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

#72

Post by youngtaff »

robbles wrote: post #18

> Instead, switching back to sending small asset files for every required element consisting the webpage being request becomes an ideal approach This doesn't solve the other side of the problem that spritesheets are meant to solve, namely that an individual image will not be loaded yet when the first UI element using it is displayed (e.g. in a CSS rollover, or new section of a SPA appears). I can't see a way that new…

Spritesheets and other forms of asset concatenation are aiming to reduce the impact of round-trip latency and overhead of HTTP i.e repeated headers.

I've always seen the "image is already loaded" as a "nice" side effect but spritesheets can have issues in mobile contexts as the whole image must be decoded jsut to access the sprite, it's unclear how effectively browsers cache the individual sprites in memory, compared to individual images too.

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

#74

Post by Iftheshoefits »

simoncion wrote: post #59
Iftheshoefits wrote: post #51

Earlier quoted context omitted.

You are correct, but missing a larger point: the ecosystem backing JSON-over-HTTP is large and expansive, and as a result development for apps built on that technology has effectively been commoditized.

0) In the late 1990's to early 2000's, exactly the same thing would have been said about XML. And yet, here we are... 1) So, you're saying that the fact that you can hire college freshman to complete your project outweighs the issues introduced by using the wrong tool for the job?

0) technologies evolve over time. JSON-over-HTTP will be supplanted by something, eventually, which almost certainly will also be something that acts to commoditize labor

1) Not me, the market. I think it is silly, too.

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

#75

Post by rkrzr »

currysausage wrote: post #40
rkrzr wrote: post #2

Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors. Is there already support for configuration files? Because for me the performance isn't the most important issue, in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. I think if you would consider adding support for the nginx config file format to H2O, thu…

> in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. Wait, you don't use Apache because you don't like .htaccess files?

Well, "main reason" may have been a bit of an exaggeration, but yes, I do think Apache's configuration syntax is truly awful.

But of course I don't mind all the other awesome features you get by using nginx.

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

#76

Post by zzzcpan »

scottlamb wrote: post #63

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 buf…

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 process each new portion of data were still very high. Instead, accept filters were used and to this day are advised in such situations by nginx people.

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

#77

Post by rapind »

kazuho wrote: post #10
rkrzr wrote: post #2

Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors. Is there already support for configuration files? Because for me the performance isn't the most important issue, in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. I think if you would consider adding support for the nginx config file format to H2O, thu…

Thank you for the comments. The configuration file format is YAML, and the directives can be seen by running `h2o --help` (the output of version 0.9.0 is: https://gist.github.com/kazuho/f15b79211ea76f1bf6e5 ). Unfortunately they are not compatible with that of Nginx. I do not think it is possible to take such approach considering the differences in the internals of both servers.

Ooh I definitely prefer your YAML configs.

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

#78

Post by jacques_chester »

liveoneggs wrote: post #48
currysausage wrote: post #40

Earlier quoted context omitted.

> in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. Wait, you don't use Apache because you don't like .htaccess files?

when wordpress is your hammer..

... everything looks like a thumb.

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

#79

Post by rubyfan »

kazuho wrote: post #10
rkrzr wrote: post #2

Congrats on shipping! This project looks very interesting already and will hopefully pick up more contributors. Is there already support for configuration files? Because for me the performance isn't the most important issue, in fact the main reason I'm using nginx over Apache is that I don't want to deal with .htaccess any more. I think if you would consider adding support for the nginx config file format to H2O, thu…

Thank you for the comments. The configuration file format is YAML, and the directives can be seen by running `h2o --help` (the output of version 0.9.0 is: https://gist.github.com/kazuho/f15b79211ea76f1bf6e5 ). Unfortunately they are not compatible with that of Nginx. I do not think it is possible to take such approach considering the differences in the internals of both servers.

@kazuho any examples of setting up filters or handlers via config?

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

#80

Post by scottlamb »

zzzcpan wrote: post #76
scottlamb wrote: post #63

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 buf…

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 also the congestion window (thus be in multiple round trips). It doesn't matter then how fast the client code is.

On looking a little now, my information may be old. Apparently Linux increased the default initial congestion window back in 2011: https://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-sta... . Is the same true for all the widely-deployed versions of iOS, Windows, and OS X?

> Instead, accept filters were used and to this day are advised in such situations by nginx people.

Hadn't seen that before: http://www.freebsd.org/cgi/man.cgi?query=accf_http&sektion=9...

Interesting feature, and certainly would the initial congestion window problem, but there doesn't seem to be an equivalent on Linux.

Post reply on HN