Both Nginx and Apache have their pro(s) and con(s). They are both used by many big tech compainies and by smaller websites. I will tell you the two sides of the Web Server Hosting!
Nginx
Nginx (also written as nginx or NGINX), came on the scene in 2004, when it was first publicly released by Russian developer Igor Sysoev. As Owen Garrett, Nginx‘ project manager said:
Nginx was written specifically to address the performance limitations of Apache web servers.
Pros of Nginx
The server was first created as a scaling tool for the website rambler.ru in 2002. It comes in two versions: open source, with BSD-type license and Nginx Plus.
After it was released, Nginx was used mostly to serve static files and as a load-balancer or reverse proxy in front of Apache installations. As the web evolved, and the need to squeeze every last drop of speed and hardware usage efficiency with it, more websites started to replace Apache with Nginx entirely, thanks also to a more mature software.
According to data from w3techs, Nginx market share has been steadily growing, pushing Apache out and dethroning it from the first place:
This data pertains to overall web servers globally, but if we take sample of the top one million websites, Nginx has been there for some time now:
Google Search Trends seems to reflect this fact as well:
Netcraft survey suggests that Apache has been overtaken by Nginx in April 2019.
Nginx Configuration
Nginx does not have a configuration system like Apache so, despite it being a lot more efficient and fast, it is not widely employed with retail hosting providers. It does not shine in shared environments as Apache does.
On the other hand, as we said, by not allowing directory-level configurations, Nginx gains a significant edge over Apache. There is an article on Nginx wiki that compares performance impact:
Nginx Modules
Nginx modules system is one more thing that positions it as a more premium choice. Nginx modules typically need to be enabled at build time, which means a more technical prowess is involved, and the post-installation adding of modules is a bit more complicated.
In 2016, with version 1.9.11, things have changed and the official/verified dynamic modules repository is reserved to the paying users. As of May 2019, they announced starting the development of support for QUIC and HTTP/3.
Handling Requests: Nginx vs Apache
The biggest difference between Apache and Nginx is in the underlying architecture of the way they handle requests.
Apache processes requests with MPM-s or Multi-Processing-Modules, which is “responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests.”
The oldest MPM, which dates back all the way to Apache‘s beginnings, is prefork module. This module alone can be credited for Apache’ performance bad reputation. Under this mode, Apache spawns new process with one thread on every request.
This module, used with mod_php, meant that Apache server embedded a PHP interpreter in every single process, even if it had to serve CSS files or images.
This was inefficient. Prefork module comes with Apache as the default module. It also restricts connections to HTTP/1.
Nginx uses asynchronous, non-blocking event-driven architecture.
To explain the difference: in the Linux/Unix world, processes are running programs.
Threads are a subset of processes and there can be multiple threads within one process execution. Think of this as multiple tabs in a browser window. This way a program can leverage multiple CPU-s and multi-core, multi-thread CPU-s to execute faster. You can read Linus Torvalds elaborating the differences.
In short, Apache uses processes for every connection (and with worker mpm it uses threads). As traffic rises, it quickly becomes too expensive.
We can picture new process or thread creation like booting up of a computer or starting up programs. Even on the fastest of computers, it still takes some time. With websites today making hundreds of requests on a single page load, this quickly adds up.
Event mpm goes a bit further in terms of optimization, but some tests show that it can’t outrun Nginx. Especially when we talk about static files, where Nginx serves as much as double the requests that Apache does.
Nginx ideally has one worker process per CPU/core. The difference of Nginx worker processes is that each one can handle hundreds of thousands of incoming network connections per worker. There is no need to create new threads or processes for each connection.
Apache
After Tim Berners-Lee’s CERN httpd and NCSA HTTPd in the first couple of years of the internet, Apache – first released in 1995 – quickly conquered the market and became the world’s most popular web server. Nowadays, it still is in that market position but mostly for legacy reasons. Apache is being developed and maintained by the Apache Foundation, under the Apache license.
There are two different stories on how Apache got its name. One version says that the name originates from the famous Native American heritage, while the other says that the name is a pun on “a patchy server”, which followed a series of software patches.
Linux
Apache’s huge market share is partly due to the fact that it comes pre-installed with all major Linux distributions, like Red Hat/Centos and Ubuntu.
One example of the important role of Apache within the Linux world is that its server process name is HTTPd, making Apache a synonym with web server software.
Besides being the first serious player in the web server market, part of Apache’s proliferation is due to its configuration system and its .htaccess file.
One example of the important role of Apache within the Linux world is that its server process name is HTTPd, making Apache a synonym with web server software.
Besides being the first serious player in the web server market, part of Apache’s proliferation is due to its configuration system and its .htaccess file.
.htaccess
Apache uses .htaccess for its configuration. There are plenty of tutorials about how to configure, edit, and work with this file as it provides a lot of flexibility in configuring how Apache handles incoming requests. Some examples are: different redirection rules, maximum upload file sizes, URL rewrites, memory limits, directory protection (htpasswd), expires headers, cache-control headers, encoding headers, cookies, query string manipulations.
On the other hand, Kinsta utilizes Nginx which doesn’t support .htaccess files. However, settings and rules from your .htaccess files can be easily “translated” to Nginx’ own rewrite rule syntax.
One of the main “Pros” of Apache is that in the server root — the main website directory — every level or directory in the directory tree can have its own .htaccess file with its own configuration.
For shared hosting providers, this is a dream because they can provide hundreds of users on the same machine a way to configure how their websites are served, without it affecting the others. Customers can configure a lot of details in a restricted shared hosting environment, while never touching the global server configuration.
As the official documentation says:
In general, you should only use .htaccess files when you don’t have access to the main server configuration file.
Every time .htaccess files are enabled, Apache has to traverse the entire directory tree from the requested URL or file through all the higher levels up until the server’s root directory and then load them, for each and every request. It then needs to process these files and reconfigure itself for each of the directories configured in this way.
With WordPress websites, things can get really complex. A typical WordPress website can have hundreds of requests from different directories.
From /wp-content/uploads/yyyy/mm type of dirs it will typically have multiple requests on a single page load, often form different month-directories. Then there will be /wp-content/themes/parent-theme static resources, /wp-content/themes/child-theme resources: these will include javascript, css files, images.
Modules
Another thing that made Apache popular is its dynamic module system.
Modules — as a feature that allows users to extend web server functionality — exist both in Nginx and Apache. Apache allows users to install modules once the web server has already been installed and deployed and then enabled/disabled them as needed. Debian-based distributions have commands that allow enabling and disabling these modules without having to edit any configuration files: a2enmod and a2dismod.
The official list of modules that come as part of Apache standard distribution is here and these include things from compression, encryption, logging, redirections to more advanced things like editing requests and responses with advanced syntax.