5 ms·

H2O – an optimized HTTP server with support for HTTP/1.x and HTTP/2

104 points by mikecarlton 11y ago

dochtman 11y ago
https://news.ycombinator.com/item?id=8342131 https://news.ycombinator.com/item?id=8342131
amelius 11y ago
Does it support websockets? And I'm hoping for an interface to the Go language.
- steeve 11y ago
  poor CGO performance would kill the benefits imho
  - amelius 11y ago
    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.
    - nindalf 11y ago
      Just curious, why would you use this instead of the server in net/http?
      - amelius 11y ago
        Speed :)
- exDM69 11y ago
  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.
anonfunction 11y ago
How does it compare to lwan? https://github.com/lpereira/lwan https://github.com/lpereira/lwan
zaide-desmarets 11y ago
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.
- SwellJoe 11y ago
  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.
  - byroot 11y ago
    > 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?
richmarr 11y ago
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

104 points by mikecarlton 11y ago

dochtman 11y ago

https://news.ycombinator.com/item?id=8342131 https://news.ycombinator.com/item?id=8342131

amelius 11y ago

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

steeve 11y ago
poor CGO performance would kill the benefits imho
- amelius 11y ago
  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.
  - nindalf 11y ago
    Just curious, why would you use this instead of the server in net/http?
    - amelius 11y ago
      Speed :)
exDM69 11y ago
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.

anonfunction 11y ago

How does it compare to lwan? https://github.com/lpereira/lwan https://github.com/lpereira/lwan

zaide-desmarets 11y ago

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.

SwellJoe 11y ago
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.
- byroot 11y ago
  > 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?

richmarr 11y ago

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