5 ms·

And the reason distros do this is because modules like mod_php and mod_perl have historically not worked well with other MPMs. As far as I'm aware this should

by breser 9y ago

And the reason distros do this is because modules like mod_php and mod_perl have historically not worked well with other MPMs. As far as I'm aware this should be resolved with newer versions of Apache and the modules. Also historically the MPM was built into the server and required a rebuild, but newer versions provide the MPM as a loadable module. But the distros have very long upgrade cycles and are hesitant to change their defaults since they don't want to break peoples existing setups. If you care about performance then you probably don't want to use the distribution's copy. People tend to use NGINX's distributions directly from NGINX or build it on their own. Since NGINX didn't have dynamic loadable modules until recently that drove more people to build their own copies. I do think it's fair to say that NGINX has a reputation for getting better performance out of the box without configuration. However, it doesn't take long before you have to start tweaking it as well in my experience. So I don't think some peoples impressions of Apache are entirely unfair but I don't think they are entirely fair either. But this shouldn't surprise anyone given that NGINX is a business and has a marketing department. Apache is a foundation and really doesn't market like NGINX does.

catdog 9y ago
I don't know about perl but for php php-fpm is basically the way to go now rendering mod_php irrelevant.
- breser 9y ago
  Yes that is very much the case, but people are still using these things.
  - catdog 9y ago
    I think mostly because they don't know better.
    - int_19h 9y ago
      It's mostly because it works for them and is good enough, so there's no strong motivation to change, especially when the old approach is so well-understood.
- jeltz 9y ago
  I have not followed Perl web development lately, but 10 years ago people were moving from mod_perl to FastCGI.
- davidgerard 9y ago
  I find if you're using PHP, it's going to be your entire CPU and memory load problem, and the server in front of it isn't. I have bothered with php-fpm previously, specifically so that when the server is getting hammered it just stops trying, instead of sending the box into OOM-killer.
peterwwillis 9y ago
Using the distro's build of Apache is actually preferred for production servers. The distro build commonly has useful patches and will receive very fast security updates, not to mention being tested much more than a one-off build. You just wouldn't use a stock configuration, for a multitude of reasons. The only reason you might compile it yourself for a performance boost is to strip out all the features, but then you have to ask yourself if you even need Apache. We used different mpms for different purposes even 10 years ago. A cluster of boxes could still serve over a hundred thousand mod_perl responses per second, at which point with a decent-sized set of perl apps your bottlenecks are application CPU and memory, not connection processing. Prefork is simply the most compatible mpm for every module that exists, so of course you'd ship that as the default for a distro. Server software being "fast out of the box" is like saying a phone's battery comes "fully charged out of the box". It's convenient, but I can also just take an hour and get it there myself.
gtirloni 9y ago
I just tested httpd 2.4.25 against nginx 1.10.3 on my workstation using the default configurations and it seems things are much better on the memory consumption area (than a quite a few years ago when we made the switch to nginx) * httpd 2.45.5, default config (prefork), peaked at 24 processes and ~8MB RSS each (192MB) => 88k req/sec * nginx 1.10.3, default config, peaked at 8 processed and ~4MB RSS each (32MB) => 199k req/sec I thought all the default modules could be slowing httpd down so I built the most stripped down version that would allow me to run it and also switched to mpm_event: * httpd 2.45.5, stripped down mpm_event, peaked at 5 processed 8MB each (40MB) ==> 89k req/sec Both mpm_prefork and mpm_event had similar numbers. Where should I be looking at if I want to increase the request rate? EDIT: stripped down mpm_prefork got me 120k req/sec but I saw a few defunct processes which is scary.
olau 9y ago
I haven't seen any marketing material from Nginx, but I think there are historic reasons for these perceptions. I've personally experienced the problems with Apache and prefork. We couldn't switch to the event model because modpython/modwsgi wouldn't work with it. And prefork was really awful when it comes to serving files. Nginx also had much better defaults. So you could use the version from the distribution and bombard it with requests without it breaking a sweat. In the end, I think convenience is really overlooked when it comes to server software, or at least has been. Most shops don't have lots of time to spend on tweaking things. The defaults must be good and necessary configuration should be simple as at all possible, autodetecting as much as possible. Not that nginx is perfect, the caching layer is one example of something that doesn't really do the right thing out of the box. Last time I looked, there was still a bunch of really common stuff it doesn't understand by default, e.g. it can get confused by compression headers or common tracking cookies. On a similar note, I once sent a bug report to Varnish that didn't at the time respect Cache-Control: private out of the box. In the end it was wontfixed by PHK.

by breser 9y ago

catdog 9y ago

I don't know about perl but for php php-fpm is basically the way to go now rendering mod_php irrelevant.

breser 9y ago
Yes that is very much the case, but people are still using these things.
- catdog 9y ago
  I think mostly because they don't know better.
  - int_19h 9y ago
    It's mostly because it works for them and is good enough, so there's no strong motivation to change, especially when the old approach is so well-understood.
jeltz 9y ago
I have not followed Perl web development lately, but 10 years ago people were moving from mod_perl to FastCGI.
davidgerard 9y ago
I find if you're using PHP, it's going to be your entire CPU and memory load problem, and the server in front of it isn't. I have bothered with php-fpm previously, specifically so that when the server is getting hammered it just stops trying, instead of sending the box into OOM-killer.

peterwwillis 9y ago

Using the distro's build of Apache is actually preferred for production servers. The distro build commonly has useful patches and will receive very fast security updates, not to mention being tested much more than a one-off build. You just wouldn't use a stock configuration, for a multitude of reasons. The only reason you might compile it yourself for a performance boost is to strip out all the features, but then you have to ask yourself if you even need Apache. We used different mpms for different purposes even 10 years ago. A cluster of boxes could still serve over a hundred thousand mod_perl responses per second, at which point with a decent-sized set of perl apps your bottlenecks are application CPU and memory, not connection processing. Prefork is simply the most compatible mpm for every module that exists, so of course you'd ship that as the default for a distro. Server software being "fast out of the box" is like saying a phone's battery comes "fully charged out of the box". It's convenient, but I can also just take an hour and get it there myself.

gtirloni 9y ago

I just tested httpd 2.4.25 against nginx 1.10.3 on my workstation using the default configurations and it seems things are much better on the memory consumption area (than a quite a few years ago when we made the switch to nginx) * httpd 2.45.5, default config (prefork), peaked at 24 processes and ~8MB RSS each (192MB) => 88k req/sec * nginx 1.10.3, default config, peaked at 8 processed and ~4MB RSS each (32MB) => 199k req/sec I thought all the default modules could be slowing httpd down so I built the most stripped down version that would allow me to run it and also switched to mpm_event: * httpd 2.45.5, stripped down mpm_event, peaked at 5 processed 8MB each (40MB) ==> 89k req/sec Both mpm_prefork and mpm_event had similar numbers. Where should I be looking at if I want to increase the request rate? EDIT: stripped down mpm_prefork got me 120k req/sec but I saw a few defunct processes which is scary.

olau 9y ago

I haven't seen any marketing material from Nginx, but I think there are historic reasons for these perceptions. I've personally experienced the problems with Apache and prefork. We couldn't switch to the event model because modpython/modwsgi wouldn't work with it. And prefork was really awful when it comes to serving files. Nginx also had much better defaults. So you could use the version from the distribution and bombard it with requests without it breaking a sweat. In the end, I think convenience is really overlooked when it comes to server software, or at least has been. Most shops don't have lots of time to spend on tweaking things. The defaults must be good and necessary configuration should be simple as at all possible, autodetecting as much as possible. Not that nginx is perfect, the caching layer is one example of something that doesn't really do the right thing out of the box. Last time I looked, there was still a bunch of really common stuff it doesn't understand by default, e.g. it can get confused by compression headers or common tracking cookies. On a similar note, I once sent a bug report to Varnish that didn't at the time respect Cache-Control: private out of the box. In the end it was wontfixed by PHK.