4 ms·

I think it's interesting that performance is mentioned as a primary feature of this. I haven't deployed a web service in nearly 15 years that had the HTTP serve

I think it's interesting that performance is mentioned as a primary feature of this. I haven't deployed a web service in nearly 15 years that had the HTTP server as the limiting factor for the performance of a website. Serving small files from RAM really fast just isn't that interesting. For this kind of workload Apache is fast enough for the vast majority of deployments (such a large majority that I've never worked on a deployment that it wasn't, and I've worked on some very large deployments), nginx is fast enough, and H2O is fast enough. Going from "fast enough" to "2x fast enough" isn't going to matter to end users who are waiting on other parts of the system. The database is still gonna be a bottleneck. The application is still gonna be a bottleneck. The disks are still gonna be a bottleneck. The network is still gonna be a bottleneck (Apache can saturate a Gbit NIC, so can nginx, so can H2O). I'm not saying this is useless. It looks like a cool project, built by someone really clever (unco is hilariously clever), with lots of good uses (an easily embedded HTTP server library is nothing to sneeze at). I'm saying I think it's weird and unfortunate that so many people focus on performance of the web server, as though it will make a difference for end users. In the vast majority of web server deployments any of the major web servers will do the job and will perform well enough to not be the bottleneck in the system.

kikoreis 12y ago
Is there a latency angle to webserver performance that /is/ valid? I have heard anecdotal information that single-thread performance does affect webserver response latency and I can see how an optimized server could make a difference there.
- SwellJoe 12y ago
  Request latency is certainly a factor, especially with more requests happening per page, and more demanding desktop-experience applications on the web. But, none of the servers I mentioned are a significant contributor to latency when configured appropriately for the workload. Apache has competent concurrency options on modern systems (including libevent), as does nginx. Certainly performance is nice. I'm not saying it isn't. But, the webserver is going to spend most of its time waiting on your application and your database. I'd like to see folks more focused on standards-compliant behavior, secure behavior, etc. That's not as easy as slapping up an ab benchmark, but it's more useful in helping me decide if a new server is appropriate for my needs, and it's helpful in moving the state of the art forward on fronts that are far more important than squeezing another bajillion requests out of hardware that can already serve a bajillion requests. Another interesting angle is memory usage. Apache does require more memory than nginx or, presumably, H2O. It's not a huge difference, if Apache is configured as minimally as nginx is, by default, but it's notable on a very high concurrency system. In the "Internet of things", small embeddable web servers will be important. If H2O uses less memory than nginx, that'd be interesting (I think more interesting than performance). But, memory usage isn't really mentioned anywhere that I see...if a memory graph were beside the ab benchmarks, I probably wouldn't have even complained about the benchmarks being so prominent. It would have added a useful and maybe even predictive piece of data to the page.
lpgauth 12y ago
Really depends on the scale you're at, but sometimes a couple CPU percent can equal saving a bunch of servers. Obviously the rest of the stack (application, db) has to also be fined tuned or else it's just pre-optimization.
- SwellJoe 12y ago
  Yes, if you have 50 web servers, saving a couple of CPU % can save a server. That said, I've never worked on a deployment that had 50 web servers, even though I've worked on a couple of major large city newspaper sites, a support site for the #2 or #3 most popular personal computer manufacturer (I don't remember what their rank was at the time), a free hosting provider that had ~12 million websites, and a handful of other interestingly large sites. Given that a single web server (Apache or otherwise) can serve millions of pages per hour, it's pretty rarefied air to be talking about 50 or 100 or more web servers. There just aren't a lot of people working on sites with that kind of traffic. I'm really not saying better performing, more efficient, web servers aren't a good thing. It's great that web servers (including Apache) continue to get faster and more efficient. I just don't think it should be the primary thing we're talking about when comparing new servers to tested and proven existing web servers. There are so many other factors, and performance doesn't matter at all if the web server doesn't do what you need it to do, or is insecure, or is unreliable.
  - staunch 12y ago
    Apache was always a badly designed HTTP server. Forking processes for every request was a stupid idea for any public web server (see also: CGI). It's the only reason web servers got Slashdotted back then and why they rarely do now. Forking processes is incredibly expensive compared to an event loop. Event-based HTTP servers inevitably won, it just took a while. Using select() wasn't ideal but then epoll() made things optimal. The idea that Apache was ever good enough was wrong then and is wrong now. We always needed a more efficient design. I'm sure someone could write an even more somewhat more efficient version of nginx but I'm not sure they could do it with as many features as nginx has. Which means you probably would just end up switching to nginx at some point. I think Cloudflare uses nginx. They probably could save on machines if they used a more minimal server.

kikoreis 12y ago

Is there a latency angle to webserver performance that /is/ valid? I have heard anecdotal information that single-thread performance does affect webserver response latency and I can see how an optimized server could make a difference there.

SwellJoe 12y ago
Request latency is certainly a factor, especially with more requests happening per page, and more demanding desktop-experience applications on the web. But, none of the servers I mentioned are a significant contributor to latency when configured appropriately for the workload. Apache has competent concurrency options on modern systems (including libevent), as does nginx. Certainly performance is nice. I'm not saying it isn't. But, the webserver is going to spend most of its time waiting on your application and your database. I'd like to see folks more focused on standards-compliant behavior, secure behavior, etc. That's not as easy as slapping up an ab benchmark, but it's more useful in helping me decide if a new server is appropriate for my needs, and it's helpful in moving the state of the art forward on fronts that are far more important than squeezing another bajillion requests out of hardware that can already serve a bajillion requests. Another interesting angle is memory usage. Apache does require more memory than nginx or, presumably, H2O. It's not a huge difference, if Apache is configured as minimally as nginx is, by default, but it's notable on a very high concurrency system. In the "Internet of things", small embeddable web servers will be important. If H2O uses less memory than nginx, that'd be interesting (I think more interesting than performance). But, memory usage isn't really mentioned anywhere that I see...if a memory graph were beside the ab benchmarks, I probably wouldn't have even complained about the benchmarks being so prominent. It would have added a useful and maybe even predictive piece of data to the page.

lpgauth 12y ago

Really depends on the scale you're at, but sometimes a couple CPU percent can equal saving a bunch of servers. Obviously the rest of the stack (application, db) has to also be fined tuned or else it's just pre-optimization.

SwellJoe 12y ago
Yes, if you have 50 web servers, saving a couple of CPU % can save a server. That said, I've never worked on a deployment that had 50 web servers, even though I've worked on a couple of major large city newspaper sites, a support site for the #2 or #3 most popular personal computer manufacturer (I don't remember what their rank was at the time), a free hosting provider that had ~12 million websites, and a handful of other interestingly large sites. Given that a single web server (Apache or otherwise) can serve millions of pages per hour, it's pretty rarefied air to be talking about 50 or 100 or more web servers. There just aren't a lot of people working on sites with that kind of traffic. I'm really not saying better performing, more efficient, web servers aren't a good thing. It's great that web servers (including Apache) continue to get faster and more efficient. I just don't think it should be the primary thing we're talking about when comparing new servers to tested and proven existing web servers. There are so many other factors, and performance doesn't matter at all if the web server doesn't do what you need it to do, or is insecure, or is unreliable.
- staunch 12y ago
  Apache was always a badly designed HTTP server. Forking processes for every request was a stupid idea for any public web server (see also: CGI). It's the only reason web servers got Slashdotted back then and why they rarely do now. Forking processes is incredibly expensive compared to an event loop. Event-based HTTP servers inevitably won, it just took a while. Using select() wasn't ideal but then epoll() made things optimal. The idea that Apache was ever good enough was wrong then and is wrong now. We always needed a more efficient design. I'm sure someone could write an even more somewhat more efficient version of nginx but I'm not sure they could do it with as many features as nginx has. Which means you probably would just end up switching to nginx at some point. I think Cloudflare uses nginx. They probably could save on machines if they used a more minimal server.