4 ms·

I started with Apache long ago, and then I moved to Nginx. 15+ years have passed. Why did Apache never become a real competitor? I didn't A/B test with Apach

by blunte 5y ago

I started with Apache long ago, and then I moved to Nginx. 15+ years have passed. Why did Apache never become a real competitor? I didn't A/B test with Apache and Nginx - I just read slashdot and later HN, and I trusted people who ran much bigger sites. But how could Nginx take such a lead that Apache could never catch up to?

vmurthy 5y ago
>I just read slashdot and later HN, and I trusted people who ran much bigger sites. But how could Nginx take such a lead that Apache could never catch up to? I read that in the last 10 years or so, this is what has happened to other successes like Slack etc : The users are becoming the decision makers as opposed to CXO handing down tools. I think developer advocacy was one of the major reasons.
toast0 5y ago
You can do a lot with the the one process per connection model of Apache 1.3 and 2.x mpm-prefork, but there are some limitations. But I think the code reorganization to support all the different mpms was a lot of work, and not a lot of benefit for everyone, so some organizations stayed with 1.x. There's a lot of jack of all trades in Apache, but if you want to handle specific conditions, you really need to tune it properly. And some of the out of the box stuff was just wrong. If you're pre-forking, you really shouldn't scale the number of children up and down, it should always run the maximum number you want to run (whatever that is). Because a connection ties up a child, you need to do a bunch of stuff to limit the time you need apache to be touching the request; you really should run an os with accept filters, and not touch the connection until the request is ready; you need a large socket buffer so you can write the whole response and close the socket and let the OS finish sending it while Apache works on the next request; you also need to disable http-keepalive (or do something crazy; Yahoo had a 'cheapalive' daemon that would pass client sockets back and forth with (y)apache --- when the connection was idle, pass to cheapalived which puts it into a select (or kqueue/epoll, I don't remember) loop; when a socket had data to read, it would be sent back to (y)apache to process the request. But the apache documentation wouldn't guide you into any of this, really. You'd try a normal seeming config, get things that worked, until it got busy, then spun up too many children and ground to a halt, probably swapping excessively on the way. Or just had too many people trying to do keep-alive and have 0% cpu and doing nothing. Or maybe spinning your wheels trying to get threaded mpm's to work (but they don't work with most of the popular mod_X's anyway). The market seems to be telling us that a big kqueue/epoll is the solution we want, but well tuned pre-fork can also do a lot; it kind of depends on if your bottleneck is the http server or if your bottleneck is your application code. If you've written your application code well enough that the http server is the bottleneck; congratulations! (or you might be a static content server, but then your bottleneck might well be your NICs or your OS TCP stack)

by blunte 5y ago

vmurthy 5y ago

>I just read slashdot and later HN, and I trusted people who ran much bigger sites. But how could Nginx take such a lead that Apache could never catch up to? I read that in the last 10 years or so, this is what has happened to other successes like Slack etc : The users are becoming the decision makers as opposed to CXO handing down tools. I think developer advocacy was one of the major reasons.

toast0 5y ago

You can do a lot with the the one process per connection model of Apache 1.3 and 2.x mpm-prefork, but there are some limitations. But I think the code reorganization to support all the different mpms was a lot of work, and not a lot of benefit for everyone, so some organizations stayed with 1.x. There's a lot of jack of all trades in Apache, but if you want to handle specific conditions, you really need to tune it properly. And some of the out of the box stuff was just wrong. If you're pre-forking, you really shouldn't scale the number of children up and down, it should always run the maximum number you want to run (whatever that is). Because a connection ties up a child, you need to do a bunch of stuff to limit the time you need apache to be touching the request; you really should run an os with accept filters, and not touch the connection until the request is ready; you need a large socket buffer so you can write the whole response and close the socket and let the OS finish sending it while Apache works on the next request; you also need to disable http-keepalive (or do something crazy; Yahoo had a 'cheapalive' daemon that would pass client sockets back and forth with (y)apache --- when the connection was idle, pass to cheapalived which puts it into a select (or kqueue/epoll, I don't remember) loop; when a socket had data to read, it would be sent back to (y)apache to process the request. But the apache documentation wouldn't guide you into any of this, really. You'd try a normal seeming config, get things that worked, until it got busy, then spun up too many children and ground to a halt, probably swapping excessively on the way. Or just had too many people trying to do keep-alive and have 0% cpu and doing nothing. Or maybe spinning your wheels trying to get threaded mpm's to work (but they don't work with most of the popular mod_X's anyway). The market seems to be telling us that a big kqueue/epoll is the solution we want, but well tuned pre-fork can also do a lot; it kind of depends on if your bottleneck is the http server or if your bottleneck is your application code. If you've written your application code well enough that the http server is the bottleneck; congratulations! (or you might be a static content server, but then your bottleneck might well be your NICs or your OS TCP stack)