Why is Apache still popular even as Nginx has proven its mettle on performance?
12 comments
A recent contract job of mine used Apache because they had written a critical component of their application as an Apache module. 10 years ago. There isn't much incentive to change it.
When people ask these questions, do they think people are actively choosing to use the old technology? That's a huge misunderstanding. It's not an apache vs nginx decision. It's do nothing vs spend precious time on a side quest to upgrade. Opportunity cost is your answer.
And re: performance, keep in mind that very few applications are limited by the speed of their HTTP server. You first look at your application servers, networks, disks, databases. If your app is truly HTTP-bound, well you're probably not still using Apache! IOW the people who NEED to upgrade from apache for performance reason already have. For the rest, there is no incentive.
When people ask these questions, do they think people are actively choosing to use the old technology? That's a huge misunderstanding. It's not an apache vs nginx decision. It's do nothing vs spend precious time on a side quest to upgrade. Opportunity cost is your answer.
And re: performance, keep in mind that very few applications are limited by the speed of their HTTP server. You first look at your application servers, networks, disks, databases. If your app is truly HTTP-bound, well you're probably not still using Apache! IOW the people who NEED to upgrade from apache for performance reason already have. For the rest, there is no incentive.
I still use Apache for some internal stuff I host. It works, has been running for over a decade, and no one has ever complained about the speed. I have no reason to invest time in changing it over.
Technology should solve business problems. If the move from Apache to nginx isn’t going to solve an actual problem, it becomes technology for technology’s sake.
In some cases, squeezing out a little extra performance does matter, but for most sites, I don’t think it’s that big of a deal.
Technology should solve business problems. If the move from Apache to nginx isn’t going to solve an actual problem, it becomes technology for technology’s sake.
In some cases, squeezing out a little extra performance does matter, but for most sites, I don’t think it’s that big of a deal.
I don’t like either so I wrote my own solution.
What killed Apache for me were the complexity of various rules and how challenging it is to define a proxy for a WebSocket connection. NGINX is better but still not great.
For me anything can be connected to anything else easily and quickly. A network connection, a socket, is a pipe containing a full duplex stream. So, just pipe one socket to another, and vice versa, and you have a very low level proxy. The rules to define such for a users customization is just as simple as what should go where.
Knowing all of that, and that HTTP is not full duplex, I serve HTTP and WebSockets from the same port with a preference for WebSockets by default. I can also pipe other streams to sockets for lower CPU overhead. I have not tested if my server is faster and less CPU overhead than NGINX yet, but it does concurrency very well.
What killed Apache for me were the complexity of various rules and how challenging it is to define a proxy for a WebSocket connection. NGINX is better but still not great.
For me anything can be connected to anything else easily and quickly. A network connection, a socket, is a pipe containing a full duplex stream. So, just pipe one socket to another, and vice versa, and you have a very low level proxy. The rules to define such for a users customization is just as simple as what should go where.
Knowing all of that, and that HTTP is not full duplex, I serve HTTP and WebSockets from the same port with a preference for WebSockets by default. I can also pipe other streams to sockets for lower CPU overhead. I have not tested if my server is faster and less CPU overhead than NGINX yet, but it does concurrency very well.
We have always used apache as a reverse proxy and it has never been a problem from a performance point of view, performance issues has always been related to the database, business logic, network, disks and so on.
Using nginx might enhance a bit performance, but compared to other modules of the overall environment such performance gains are neglectable and unnoticeable for a normal user.
In our latest product I wanted to switch to nginx but I was surprised that for windows it is only in BETA version, and since our application MUST be deployable to both Windows and Linux environments we preferred a consistent software stack hence we stick on Apache.
The plan is to reconsider nginx once it officially supports windows, since no serious customer would accept a beta version for a production environment.
Using nginx might enhance a bit performance, but compared to other modules of the overall environment such performance gains are neglectable and unnoticeable for a normal user.
In our latest product I wanted to switch to nginx but I was surprised that for windows it is only in BETA version, and since our application MUST be deployable to both Windows and Linux environments we preferred a consistent software stack hence we stick on Apache.
The plan is to reconsider nginx once it officially supports windows, since no serious customer would accept a beta version for a production environment.
old habits, documentation and just lazy practices like using it out of the box, I personally used Apache, nginx and OLS and lately been leaning more and more on open-light-speed for the fact that it can handle more traffic on less resources
Legacy code and online documentation. Apache was THE web server for PHP. But it was getting slow, so new alternatives started to pop up. But the ecosystem of manuals, libraries and integrations never went away.
Simpler, better module ecosystem and better rewrites.
FPM workers get stuck, default settings need to be changed, can’t handle long-running connections well, ends up using a lot of ram. More log places to check when things go wrong.
You end up with more issues.
FPM workers get stuck, default settings need to be changed, can’t handle long-running connections well, ends up using a lot of ram. More log places to check when things go wrong.
You end up with more issues.
The only logical explanation I can think of based on my personal experience is that shared hosting services offer Apache web server by default so they can host WordPress websites which by the way, based on w3techs.com, 43.1% of all websites are WordPress.
You may ask why Apache then? Well, because when a user modify some settings via dashboard, they change in .htaccess which does not expect a web server restart or super user permissions like you need with NGINX, for example.
Now you know why WordPress websites are getting hacked easier than other CMS-es...because they can apply changes in .htaccess on the fly, whereas with other web servers, you need root permissions, thus the extra layer of security.
You may ask why Apache then? Well, because when a user modify some settings via dashboard, they change in .htaccess which does not expect a web server restart or super user permissions like you need with NGINX, for example.
Now you know why WordPress websites are getting hacked easier than other CMS-es...because they can apply changes in .htaccess on the fly, whereas with other web servers, you need root permissions, thus the extra layer of security.
If you are a company who does some non-IT thing, it makes sense to stick to the LAMP stack because it has the largest and most thorough knowledge bases online.
I think a lot of people take a "If it ain't broke don't fix it" approach to these things. Breaking a reverse proxy can be catastrophic
If you've already gotten used to one custom ad hoc confusing configuration language...
As I understand, the popular consensus today is that nginx+php-fpm performs faster than apache even with the mpm_event process management enabled?
This was certainly true long ago in Apache HTTPD 2.2. They completely rewrite APR and as of the 2.4 branch it was on par with Nginx.
Some use Apache for a tighter integration with some modules such as PHP resulting is a slightly better security stance with PHP. Nginx makes heavy use of fcgi wrappers and there are a number of foot-guns people create when making their own applications just as PHP itself has a number of foot-guns.
I use both NGinx and Apache depending on what I am deploying and often have HAProxy in front of it on many nodes unless I am just serving static content and then it does not really matter. There is no one correct answer. What people use will depend on what they are doing and also what they are comfortable with. The arguments I have seen about Apache vs Nginx are on par with browser war arguments, cell phone arguments, favorite color and so on. Both NGinx and Apache have their share of design flaws and I have been in long heated arguments with the lead developers of both. People should use what they have the most experience with and can feel reasonably confident that they have done proper due diligence regarding security before performance. This is all unrelated to CVE counts but rather sysadmin PEBKAC [0] issues.
[0] - https://www.urbandictionary.com/define.php?term=PEBKAC
This was certainly true long ago in Apache HTTPD 2.2. They completely rewrite APR and as of the 2.4 branch it was on par with Nginx.
Some use Apache for a tighter integration with some modules such as PHP resulting is a slightly better security stance with PHP. Nginx makes heavy use of fcgi wrappers and there are a number of foot-guns people create when making their own applications just as PHP itself has a number of foot-guns.
I use both NGinx and Apache depending on what I am deploying and often have HAProxy in front of it on many nodes unless I am just serving static content and then it does not really matter. There is no one correct answer. What people use will depend on what they are doing and also what they are comfortable with. The arguments I have seen about Apache vs Nginx are on par with browser war arguments, cell phone arguments, favorite color and so on. Both NGinx and Apache have their share of design flaws and I have been in long heated arguments with the lead developers of both. People should use what they have the most experience with and can feel reasonably confident that they have done proper due diligence regarding security before performance. This is all unrelated to CVE counts but rather sysadmin PEBKAC [0] issues.
[0] - https://www.urbandictionary.com/define.php?term=PEBKAC
But when it comes to real world usage, many production instances I observe these days still deploy apache a lot. Even cpanel based web hosting (shared or dedicated instances) are more often apache based than nginx.
Is it due to some old habits and dependence on apache specific features like .htaccess support? Or is it the case that apache has actually caught up in the race with ngnix and the performance difference is quite negligible these days?