Hacker News new | past | comments | ask | show | jobs | submit login
[dupe] H2O – an optimized HTTP server with support for HTTP/1.x and HTTP/2 (github.com/h2o)
104 points by mikecarlton on May 19, 2015 | hide | past | favorite | 12 comments




What's the purpose of benchmarking HTTP requests to a 6Bytes contents? HTTP contents are more between ~50KB on the web no?

The difference is not so obvious when file size increase compare to nginx.


While I pretty much agree with you that microbenchmarks are always suspect, it's also worth noting that HTTP2 will change the landscape a bit. All those bundles of icons in fonts and sprites can be loaded in parallel going forward...so, lots more very small files.

Further, I rarely worry much about web server performance, because I have so many other pieces in the stack that are the bottlenecks. In fact, almost everything in my web application stack is slower than my web server...so, I don't sweat the web server, except in cases where I can find a good argument that it matters. So, a benchmark of one very fast web server against another very fast web server (and most of the major players are very fast, at this point) is not going to convince me to change.


> All those bundles of icons in fonts and sprites can be loaded in parallel going forward

The protocol offers to push files indeed, but AFAIK we're yet to see any application side support for that. So I doubt it will matter anytime soon.

I'm not even sure how it could be integrated to the current rack /WSGI / etc model. Maybe with X-Send-File type headers?


I find a performance-based sales pitch much less appealing than one that told me the primary focuses were security and predictability of configuration. Too many hours spent pulling my hair out with Nginx config


How does it compare to lwan?

https://github.com/lpereira/lwan


Does it support websockets? And I'm hoping for an interface to the Go language.


Yes, it does support WebSockets. There is an example of doing a WebSocket server using libh2o + libuv + libwslay in the repo.

I tinkered around with that a little, it seemed pretty solid.


poor CGO performance would kill the benefits imho


I guess it depends. For example, not if the Go interface would be used merely for the websocket part, while the raw content is still served by the C code alone.


Just curious, why would you use this instead of the server in net/http?


Speed :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: