The Internet, as we know it today, began its global “conquest” in the 90s. The entire “Web” protocol can be summarized as a visitor requesting a document from a given web address, with the DNS and IP system forwarding that request to the correct computer. This computer, which hosts the requested web page, will “serve” the web page to the visitor.
Web pages are essentially HTML documents. In order to serve different web pages to visitors, the “servant” machine needs a server program. Software like Nginx vs Apache handles requests, parses them, and then returns the corresponding documents for viewing in a visitor’s browser.
Apache
We will dive into Apache first since it was released first
.
After Tim Berners-Lee’s CERN httpd and NCSA HTTPd in the early years of the Internet, Apache, first launched in 1995, quickly conquered the market and became the world’s most popular web server. Today, it is still in that market position, but mainly for inherited reasons. Apache is being developed and maintained by the Apache Foundation, under the Apache License.
There are two different stories about how Apache got its name. One version says the name originates from the famous Native American heritage, while the other says the name is a play on words with “an irregular 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, such as Red Hat/Centos and
Ubuntu.
An example of Apache’s important role within the Linux world is that its server process name is HTTPd, making Apache synonymous with web server software.
In addition to 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 many tutorials on how to configure, edit, and work with this file, as it provides a lot of flexibility to configure how Apache handles incoming requests. Some examples are: different redirection rules, maximum upload file sizes, URL rewrites, memory limits, directory protection (htpasswd), expired headers, cache control headers, encryption headers, cookies, query string manipulations.
On the other hand, Kinsta uses Nginx which does not support .htaccess files. However, the settings and rules of your .htaccess files can be easily “translated” into the Nginx rewrite rule syntax itself.
One of the main “
Pros” of Apache is that at the root of the server, the main directory of the website, each level or directory in the directory tree can have its own .htaccess file with its own settings.
For shared hosting providers, this is a dream because they can provide hundreds of users on the same machine with a way to configure how their websites are served, without it affecting others. Customers can configure many details in a restricted shared hosting environment, without touching the global server settings.
As the official documentation says:
“In general, you should only use .htaccess files
when you don’t have access to the primary server configuration file.”
This flexibility, however, comes at the expense of performance “allowing .htaccess files causes a performance impact, whether you use them or not!” Each time .htaccess
files are enabled, Apache has to traverse the entire directory tree from the requested URL or file through all levels top them to the root directory of the server and then upload them, for each and every request. It then needs to process these files and reconfigure 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.
Since the dirs type /wp-content/uploads/yyyy/mm, you will normally have multiple requests on a single page load, often forming different monthly directories. Then there will be static resources /wp-content/themes/parent-theme, /wp-content/themes/child-them: these will include javascript, css files, images.
Then there will also be /wp-content/plugins with static files loaded from often dozens of plugin subdirectories. For each of these resources, Apache has to traverse its entire tree to find the configuration.
An analysis has shown that a typical WordPress setup, fairly common for websites on shared hosts, will include 42 separate .htaccess executions and 249 separate appearances for the .htaccess file.
This is only at the web server level. The visitor still has to wait for the PHP process to run the entire WordPress call stack to create the database query and give it to MySQL to assemble the web page and send it to the visitor.
Another
thing that made Apache popular is its dynamic module system
.
Modules, as a feature that allows users to extend web server functionality, exist in both 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 you to enable and disable these modules without having to edit any configuration files: a2enmod and a2dismod.
The official list of modules that come as part of the standard Apache distribution is here and these include things from compression, encryption, logging, redirects to more advanced things like edit requests and responses with advanced syntax.
Nginx
Nginx
(also written as nginx or NGINX), entered the scene in 2004, when it was first publicly released by Russian developer Igor Sysoev. As Owen Garrett, project manager at Nginx, said,
“Nginx was written specifically to address the performance limitations of Apache web servers.”
The server was first created as a scaling tool for the rambler.ru website in 2002. It comes in two versions: open source, licensed BSD-like, and Nginx Plus, with additional enterprise support and features.
After its release, Nginx was mainly used 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 efficiency of using hardware with it, more websites began to replace Apache with Nginx entirely, thanks also to more mature software.
<img src="https://kinsta.com/wp-content/uploads/2019/06/nginx.jpg" alt="NGINX Inc acquired by F5 Networks
Inc acquired by F5 Networks
In March 2019, Nginx Inc was acquired by F5 Networks for $670 million. At the time, as Techcrunch reports, the Nginx server was powering “375 million websites with about 1,500 paying customers.”
According to
w3techs data, Nginx’s market share has been growing steadily, pushing Apache and dethroning it from the first place
:
WebThis data pertains to web servers in general globally, but if we take a sample of the top one million websites, Nginx has been there for a long time. some time
: 
Percentage of websites using Nginx Google
Search Trends also seems to reflect this fact
:
src=”https://kinsta.com/wp-content/uploads/2019/06/Google-Search-Trends-Apache-vs-Nginx-1.png” alt=”Google Search Trends: Nginx vs
Netcraft survey suggests Apache has been overtaken by Nginx in April 2019
.
Nginx configuration does
not
have a configuration system like Apache, so despite being much more efficient and faster, it is not widely employed with retail hosting providers. It doesn’t shine in shared environments like Apache does.
other hand, as we said, by not allowing directory-level configurations, Nginx gains a significant advantage over Apache. There is an article on
the Nginx wiki that compares the performance impact: <img src="https://kinsta.com/wp-content/uploads/2019/06/performance-impact-nginx-vs-apache.png" alt="Nginx vs Apache performance impact.png
module system It’s one more thing that positions it as a more premium option. Nginx modules usually need to be enabled at build time, which means this is a more technical skill, and adding modules after installation is a bit more complicated.
In 2016, with version 1.9.11, things have changed and the official/verified dynamic module repository is reserved for paid users. As of May 2019, they announced the start of development of support for QUIC and HTTP/3.
The Caching
Issue: Nginx vs Apache Caching
,
if we want to oversimplify it, can be imagined as preparing content for website visitors before they visit so that when they “knock on the door,” you don’t need to search for the content they’re looking for. You already have it prepared and you deliver it without waiting.
Like Apache, the typical configuration of Nginx used to be sitting between the servers and the end user to alleviate the performance impact of the rest of the infrastructure. In these cases, you can cache static content without having to obtain it from the protected source server each time.
If we use Nginx as a standalone web server, as is the case with Kinsta LXC containers, there is no such need. Nginx is very efficient at serving static content on its own.
Then there is the question of dynamic caching or page caching. In the scenario of a WordPress website, this means storing all the WordPress pages generated for each URL in memory or on disk.
FastCGI caching is available natively in a standard Nginx installation. It is simple, very powerful and one of the least used features of Nginx.
To compare this to Apache equivalents, you should know that Apache has mod_cache module that reportedly tends to be flawed, conflicting with other modules. Therefore, the standard caching solution implemented with Apache is the Varnish HTTP accelerator. Although Varnish is the industry’s dedicated solution, some recent tests give Nginx a distinct advantage over Varnish.
At Kinsta, we use Nginx for WordPress dynamic caching, along with a proprietary caching plugin that allows granular control over cached pages and static assets cached by Kinsta CDN.
Request Handling: Nginx
vs
Apache
The biggest difference between Apache and Nginx is in the underlying architecture of how 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 sending children to handle requests.”
The oldest MPM, dating back to the beginnings of Apache, is the prefork module. This module alone can be credited for Apache’s poor performance reputation. Under this mode, Apache generates a new process with one thread in each request.
This module, used with mod_php, meant that the Apache server embedded a PHP interpreter in every process, even if it had to serve CSS files or images.
This was inefficient. The Prefork module comes with Apache as the default module. It also restricts connections to HTTP/1.
In later years, Apache has developed multithreaded working mpm and after that, the mpm event. Both alleviate many of Apache’s performance issues. Switching to php-fpm makes it possible for Apache to remain a competing solution today, along with the elimination of the use of .htaccess, but that defeats its purpose.
Nginx uses an asynchronous, non-blocking event-based 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 the execution of a process. Think of this as multiple tabs in a browser window. In this way, a program can leverage multiple CPU-s and multi-core and multi-threaded CPU-s to run faster. You can read Linus Torvalds elaborating on the differences.
In short, Apache uses processes for each connection (and with worker mpm it uses threads). As traffic increases, it quickly becomes too expensive.
We can imagine a new process or thread creation, such as starting a computer or starting programs. Even on the fastest computers, it still takes some time. With today’s websites making hundreds of requests in a single page load, this adds up quickly.
Event mpm goes a bit further in terms of optimization, but some tests show that it can’t beat Nginx. Especially when we talk about static files, where Nginx serves up to twice as many requests as Apache.
Nginx ideally has one worker process per CPU/core. The difference of Nginx worker processes is that each can handle hundreds of thousands of incoming network connections per worker. You do not need to create new threads or processes for each connection.
This is why major content delivery networks, such as
Cloudflare, MaxCDN and our partner KeyCDN, or websites such as Netflix, consider Nginx to be crucial to their content delivery.
The list of companies taking advantage of Nginx is too long to list them all, so we’ll end with Automattic, The private company behind WordPress.com.
Automattic converted all of its load balancers to Nginx for WordPress.com in 2008 (you can read about this here) and migrated its server stack entirely to Nginx.
If
we want to inspect what the website uses in production, we can usually find it in the HTTP response headers. This means that we will have to right-click on a website > Inspect, in the developer tools, we will choose the network panel and then reload the website. We will see all the resources that the website is loading. If we choose a particular resource and its Headers tab, we will usually see the server information. If the website uses CDN, we can see something like Cloudflare on the server line or something like Varnish if the website uses the HTTP accelerator.
Here is an example of a
WordPress website that uses a typical shared hosting setup with cPanel, Apache, and PHP
: 
Apache HTTP header
This is a website in
Nginx:
=”https://kinsta.com/wp-content/uploads/2019/06/nginx-http-header.png” alt=”Nginx
On the left side, if we expand it, we can also analyze the time of each resource and see its impact on the total page load time.
Nginx vs Apache: Which Provides Faster Solutions for Your WordPress Sites? 🚀 Check out our showdown on the web server! In
this article, I focused on Nginx vs Apache and explained the main architectural differences that helped Nginx gain more traction and attention within the realm of web servers. These are the key traits that give you the performance advantage in our resource-hungry industry.
Of course, not all use cases have the same priorities and Apache or other tools like Lighttpd, IIS, LiteSpeed, Caddy could be good solutions.
At Kinsta, we use Nginx as part of our performance-optimized hosting solutions for WordPress and WooCommerce. Each WordPress site is hosted in its own isolated container, which has all the software resources needed to run it (Nginx, Linux, PHP, MySQL). Resources are 100% private and are not shared between any other site.
Be sure to check out Nginx and all our premium plugins. Also, check out our application hosting and database hosting services for more hosting opportunities.