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

11–20 of 85 posts

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

#11

Post by Someone »

Shish2k wrote: post #3

Looking at the tangentially linked qrintf project that H2O uses ( https://github.com/h2o/qrintf ), replacing generic sprintf calls with specialised versions for a 10x speed boost - that seems like a brilliant idea, I wonder why it took so long for somebody to think of it?

A quick google gave me https://gcc.gnu.org/ml/gcc/2007-10/msg00073.html, so at least somebody thought of it over 7 years ago.

Also, http://www.ciselant.de/projects/gcc_printf/gcc_printf.html#p... shows gcc did something in this area 9 years ago.

http://www.cygwin.com/ml/libc-hacker/2001-08/msg00003.html indicates gcc had printf optimizations in 2001.

I expect there are older examples.

qrintf seems to be 'just' a more aggressive version of this.

I guess being more aggressive makes sense in applications that do a lot of simple string formatting.

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

#12

Post by kazuho »

jarnix wrote: post #5

Obviously it's great software. Does Kazuho work alone on this ? If it's meant to replace nginx, it needs a lot of other options/functions/extensions/modules/... Is it getting commercial support/funds ?

Contributors are highly welcome, obviously!

For myself, developing H2O is part of my job at DeNA (one of the largest smartphone game providers in Japan).

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

#14

Post by kazuho »

PythonicAlpha wrote: post #7

Looks very promising! I am not so much into web-servers (yet), but I found this in the feature list: reverse proxy HTTP/1 only (no HTTPS) Are there any plans to add also HTTPS-support for reverse proxy? Since I have to include a secondary (Tornado) web-server unto my stack for dynamic pages. It also puzzled me, that https is not supported, but in the benchmarks I found a part: "HTTPS/2 (reverse-proxy)". As I said, I…

Sorry for the confusion.

HTTP and HTTPS (both version 1 and 2) are supported for downstream connections (i.e. connection bet. H2O and web browsers). Only plain-text HTTP/1 is supported for upstream connections (connection bet. H2O and web application servers).

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

#16

Post by nly »

Shish2k wrote: post #3

Looking at the tangentially linked qrintf project that H2O uses ( https://github.com/h2o/qrintf ), replacing generic sprintf calls with specialised versions for a 10x speed boost - that seems like a brilliant idea, I wonder why it took so long for somebody to think of it?

One of the problems with compiling print/scanf is that a lot of the overhead comes from locale handling, which is a runtime variable. Parsing is fairly negligible for short format strings.

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

#17

Post by PythonicAlpha »

kazuho wrote: post #14
PythonicAlpha wrote: post #7

Looks very promising! I am not so much into web-servers (yet), but I found this in the feature list: reverse proxy HTTP/1 only (no HTTPS) Are there any plans to add also HTTPS-support for reverse proxy? Since I have to include a secondary (Tornado) web-server unto my stack for dynamic pages. It also puzzled me, that https is not supported, but in the benchmarks I found a part: "HTTPS/2 (reverse-proxy)". As I said, I…

Sorry for the confusion. HTTP and HTTPS (both version 1 and 2) are supported for downstream connections (i.e. connection bet. H2O and web browsers). Only plain-text HTTP/1 is supported for upstream connections (connection bet. H2O and web application servers).

Thank you very much for the answer!

To clarify for my mind:

Can I than use H2O to connect to a web-browser via HTTPS and H2O is routing the same request upstream via HTTP to a web application server? (that of course would suffice for me).

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

#18

Post by robbles »

> 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 protocols are going to solve this, unless I'm missing something in how HTTP2 is going to be handled by the browser?

I assume that once you're forced to preload everything you might need for the page, it's no longer more efficient to break up into multiple tiny requests.

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

#19

Post by mp3geek »

kazuho wrote: post #14
PythonicAlpha wrote: post #7

Looks very promising! I am not so much into web-servers (yet), but I found this in the feature list: reverse proxy HTTP/1 only (no HTTPS) Are there any plans to add also HTTPS-support for reverse proxy? Since I have to include a secondary (Tornado) web-server unto my stack for dynamic pages. It also puzzled me, that https is not supported, but in the benchmarks I found a part: "HTTPS/2 (reverse-proxy)". As I said, I…

Sorry for the confusion. HTTP and HTTPS (both version 1 and 2) are supported for downstream connections (i.e. connection bet. H2O and web browsers). Only plain-text HTTP/1 is supported for upstream connections (connection bet. H2O and web application servers).

Is spdy supported?

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

#20

Post by stephth »

Interesting 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 project of this type in C today?

[1] http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

Edit: why the downvotes?

Post reply on HN