11 ms·

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)

by 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.
  - sciurus 12y ago
    It's a good thing we have http://httpd.apache.org/docs/current/mod/event.html http://httpd.apache.org/docs/current/mod/event.html then.
    - eropple 12y ago
      I've spent a decent amount of time trying to make evented Apache work. It's never been worth it when a better choice that just does it is right there for the taking. (And god help you if you try to do it with Passenger.)
  - SwellJoe 12y ago
    So, you don't know enough to know that Apache is not tied to any particular concurrency model, nor has it used the concurrency implementation you've described (process-per-connection) in decades, yet you feel you know enough to make recommendations for web servers? Even if using Apache in the now quite old prefork MPM, it is a process pool, rather than a process-per-connection that you've described, and is not subject to the performance problems you're alleging (memory usage can be high when using that MPM for high concurrency workloads, but its performance in most deployments is not all that bad). Further, "forking processes" is actually not incredibly expensive on Linux, and in fact, pthreads on Linux are implemented by the same code (clone() with varying levels of sharing). Forked applications on Linux are pretty much just as fast as threaded applications. It is a myth based on extremely outdated knowledge (fork on Solaris, for instance, and some other UNIX variants, had a history of being slow; but, Linux has always had a very fast fork). It is true that event-based thread (or process) pool concurrency implementations can provide superior performance to thread- or process-per-connection implementations, for a variety of reasons, but Apache has that covered. I'm gonna guess you've never even used or seen an Apache installation that forked a process for every request (because it's been so long since that was a thing Apache did), so I'm not sure how you could believe it works that way. Where did you get all of these assertions from? Are there sites out there propagating these crazy claims about Apache? And, if so, why? What does one gain by trash-talking a project that was instrumental in helping build the open web and still powers more websites than any other web server in the world? And, does it well, I might add. There are some good reasons a reasonable admin might choose nginx over Apache. But, they aren't because Apache is a terrible piece of software written by incompetent people. In short, your comment has negative value, by providing misleading and outright incorrect information. Edit: And, this is why I hate it when performance is the measuring stick people use to discuss web servers. It begins to seem like it is a useful metric for comparing web servers, when it really is not for 99% (or more) of deployments. Apache is fast enough. nginx is fast enough. Pick your web server based on other characteristics, because otherwise you're almost certainly making decisions based on the wrong things.

by lpgauth 12y ago

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.
- sciurus 12y ago
  It's a good thing we have http://httpd.apache.org/docs/current/mod/event.html http://httpd.apache.org/docs/current/mod/event.html then.
  - eropple 12y ago
    I've spent a decent amount of time trying to make evented Apache work. It's never been worth it when a better choice that just does it is right there for the taking. (And god help you if you try to do it with Passenger.)
- SwellJoe 12y ago
  So, you don't know enough to know that Apache is not tied to any particular concurrency model, nor has it used the concurrency implementation you've described (process-per-connection) in decades, yet you feel you know enough to make recommendations for web servers? Even if using Apache in the now quite old prefork MPM, it is a process pool, rather than a process-per-connection that you've described, and is not subject to the performance problems you're alleging (memory usage can be high when using that MPM for high concurrency workloads, but its performance in most deployments is not all that bad). Further, "forking processes" is actually not incredibly expensive on Linux, and in fact, pthreads on Linux are implemented by the same code (clone() with varying levels of sharing). Forked applications on Linux are pretty much just as fast as threaded applications. It is a myth based on extremely outdated knowledge (fork on Solaris, for instance, and some other UNIX variants, had a history of being slow; but, Linux has always had a very fast fork). It is true that event-based thread (or process) pool concurrency implementations can provide superior performance to thread- or process-per-connection implementations, for a variety of reasons, but Apache has that covered. I'm gonna guess you've never even used or seen an Apache installation that forked a process for every request (because it's been so long since that was a thing Apache did), so I'm not sure how you could believe it works that way. Where did you get all of these assertions from? Are there sites out there propagating these crazy claims about Apache? And, if so, why? What does one gain by trash-talking a project that was instrumental in helping build the open web and still powers more websites than any other web server in the world? And, does it well, I might add. There are some good reasons a reasonable admin might choose nginx over Apache. But, they aren't because Apache is a terrible piece of software written by incompetent people. In short, your comment has negative value, by providing misleading and outright incorrect information. Edit: And, this is why I hate it when performance is the measuring stick people use to discuss web servers. It begins to seem like it is a useful metric for comparing web servers, when it really is not for 99% (or more) of deployments. Apache is fast enough. nginx is fast enough. Pick your web server based on other characteristics, because otherwise you're almost certainly making decisions based on the wrong things.