Live data from Hacker News

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

blog.kazuhooku.com

21–30 of 85 posts

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

#21
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…

> 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?

HTTP/2 server push. Your server can proactively deliver things like rollover state graphics knowing that the client will need them.

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

#22
post #15

Another one to keep an eye on might be the new httpd in OpenBSD. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/... I'm not seeing that there is yet a portable version however.

It is not intended to be anything other than a minimal secure http 1 server, not performant.

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

#23
post #16
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.

Few applications want locale support. Mostly you want reproducible output.

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

#24
post #20

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

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.

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

#25
post #19
post #14

Earlier quoted context omitted.

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?

spdy == http 2

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

#26
post #20

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

Not relevant to the article "doesn't apply to H2O as it's been in the works for a while looking at the commits"...

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

#27
post #20

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

I think, it is because language fights are not appreciated so much here.

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

#28
post #19

Earlier quoted context omitted.

Is spdy supported?

spdy == http 2

Is it really the same (really asking)?? Sometimes there are subtle protocol changes, when something is standardized -- and as much I understand, HTTP/2 took a while ...

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

#29
post #21
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…

> 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? HTTP/2 server push. Your server can proactively deliver things like rollover state graphics knowing that the client will need them.

good point. I imagine determining when to push these assets will become a complex choice though.

Also, I realized shortly after commenting that I missed the obvious benefit of avoiding downloading global spritesheets and other compiled assets for individual pages that only use a subset of the content.

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

#30

Earlier quoted context omitted.

spdy == http 2

Is it really the same (really asking)?? Sometimes there are subtle protocol changes, when something is standardized -- and as much I understand, HTTP/2 took a while ...

the initial http 2.0 draft was just a copy of spdy (in nov 2012). There have been changes to 2.0, so they aren't exactly the same.. but http 2.0 is meant to completely replace spdy.

Any of the servers/clients that support spdy currently will eventually make the minor changes, and call it http 2.0.

Post reply on HN