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.
Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
51–60 of 85 posts
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#52Congrats 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…
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
#53However, 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.
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#54However, 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
#55Very 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…
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#56Socket 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.
Re: Show HN: Initial release of H2O, and why HTTPD performance will matter in 2015
#57Very 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
#58Very 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/
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
#59Earlier 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.
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?