Live data from Hacker News

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

blog.kazuhooku.com

51–60 of 85 posts

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

#51
post #46

Earlier quoted context omitted.

Why? What's wrong with this approach?

Latency, for one. "Microservice" means reaching out over the network to perform an action, not necessarily: make an HTTP connection, transfer JSON, receive JSON back and deserialize. Microservices can just as readily be performed via protocol buffers or Thrift over ZeroMQ, raw TCP/UDP, etc.

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.

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

#52
post #9
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…

nginx' configuration format leaves a lot to be desired, as evidenced by the (former, hopefully) widespread use of exploitable php calls. There are also if directives in there, but they don't really work they way you think. You really need a deep understanding of its parsing rules in order to do anything remotely complicated with it. It's certainly possible to do better. (Please don't mention Apache here and its steam…

Like a lot of configurations formats the semantics of nginx's config files has pitfalls: http://wiki.nginx.org/IfIsEvil

Not a fan of nginx's config but I'm a huge fan of nginx.

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

#53
Very nice work, competition is always good.

However, it seems worth mentioning that webservers haven't been a bottleneck for a long time now. Your bottleneck is always disk I/O, the network, or the slow application server that you're proxying to.

For reference: Wikipedia[1] serves roughly 8k pageviews/sec on average for a total of ~20 billion pageviews/month.

Assuming each pageview consists of ~10 webserver hits we're looking at ~80k requests/sec.

This is within the realm of a single instance of either nginx or h2o on a beefy machine [on a very beefy network].

So, unless you plan to serve Wikipedia or Facebook from a single server, you're probably fine picking your webserver software on the basis of features rather than benchmarks.

[1] http://reportcard.wmflabs.org/graphs/pageviews

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

#54
That's a cool project. Performance is a fascinating topic.

However, in the real world, the number of requests per second a http daemon can perform is the last thing to worry about. If the web is slow, it's not because Apache used to be bloated with thread. It's because of bad architecture: centralization of services, latency in page builds time, size of static components, data store bottlenecks, etc...

Nevertheless, a very cool project. One I'll follow closely.

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

#55
post #53

Very nice work, competition is always good. However, it seems worth mentioning that webservers haven't been a bottleneck for a long time now. Your bottleneck is always disk I/O, the network, or the slow application server that you're proxying to. For reference: Wikipedia[1] serves roughly 8k pageviews/sec on average for a total of ~20 billion pageviews/month. Assuming each pageview consists of ~10 webserver hits we'r…

You may be a bit off with your calculation. Wikipedia uses 15,000 cpus on 750 hosts. http://ganglia.wikimedia.org/latest/

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

#56
post #13

Socket API is a bottleneck now, right? So, next step: roll your own http-friendly tcp stack on top of netmap/dpdk and get 10x performance increase over nginx.

IX is something like that: https://www.usenix.org/conference/osdi14/technical-sessions/...

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

#57
post #53

Very nice work, competition is always good. However, it seems worth mentioning that webservers haven't been a bottleneck for a long time now. Your bottleneck is always disk I/O, the network, or the slow application server that you're proxying to. For reference: Wikipedia[1] serves roughly 8k pageviews/sec on average for a total of ~20 billion pageviews/month. Assuming each pageview consists of ~10 webserver hits we'r…

You may be a bit off with your calculation. Wikipedia uses 15,000 cpus on 750 hosts. http://ganglia.wikimedia.org/latest/

Thanks. Do you know of any references on Wikipedia's architecture for the host types named in the Ganglia report?

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

#58
post #53

Very nice work, competition is always good. However, it seems worth mentioning that webservers haven't been a bottleneck for a long time now. Your bottleneck is always disk I/O, the network, or the slow application server that you're proxying to. For reference: Wikipedia[1] serves roughly 8k pageviews/sec on average for a total of ~20 billion pageviews/month. Assuming each pageview consists of ~10 webserver hits we'r…

You may be a bit off with your calculation. Wikipedia uses 15,000 cpus on 750 hosts. http://ganglia.wikimedia.org/latest/

You may be a bit off with your calculation

Where?

Wikipedia uses 15,000 cpus on 750 hosts.

These are not all webservers.

Also, even though they could run their load on a fraction of the hardware it would probably not make a lot of sense to optimize for that, as the potential cost savings are relatively small (servers are cheap).

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

#59

Earlier quoted context omitted.

Latency, for one. "Microservice" means reaching out over the network to perform an action, not necessarily: make an HTTP connection, transfer JSON, receive JSON back and deserialize. Microservices can just as readily be performed via protocol buffers or Thrift over ZeroMQ, raw TCP/UDP, etc.

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?

Post reply on HN