Posted on October 4th, 2017
Apache and Nginx are the most popular open source web servers in the world. Between the two of them, they serve about 50% of the traffic on the internet. While both of them are capable of handling large workloads in a variety of different environments, sometimes it’s hard to tell which one is the right choice for your setup.
Before we go into detail about the differences, we should start with a basic overview of the two platforms and their general details
The Apache HTTP server is an open source Web Server application. It is managed by the Apache Software Foundation. It is freely distributed under an Open Source License, which means that users can edit the underlying code to tweak performance and contribute to future developments.
Apache will run on most, if not all, major operating systems (Linux, Windows, MacOS, etc), but is most commonly run on Linux. When combined with MySQL and PHP this makes up the popular LAMP Web Server solution (which literally stands for Linux, Apache, MySQL & PHP).
Apache has been the market leader for most of it’s life, since it’s creation in the mid 90s. Nowadays, however, it’s only slightly ahead of it’s main competitors, Microsoft’s IIS and Nginx.
Nginx (Pronounced “Engine-X”) was released to the public in 2004. Originally designed in response to the C10K challenge, which was to handle 10,000 simultaneous client connections on a single server, Nginx is light-weight and capable of serving static content quickly.
Like Apache, Nginx is capable of running on most operating systems, though it is only partially supported on Windows.
One of the major differences between Apache and Nginx is how they handle connections.
Apache provides a variety of options about how to handle connections. These are referred to as Multi-Processing Modules (or MPMs). This allows administrators to easily change it’s connection handling architecture to match the environment. These options are:
- mpm_prefork: This module spawns a separate, single thread, process for each request. As long as there are less requests than the number of processes this MPM is very fast, however once the number of requests increases performance can degraded quickly. This module is recommended in cases when the other applications involved don’t work well with multiple threads per process, like mod_php.
- mpm_worker: This module spawns processes that each manage multiple threads. Threads are more efficient than processes, which means that this module scales better that the prefork MPM.
- mpm_event: This module runs similarly to the worker MPM in most situations, but it’s designed primarily to handle keep-alive connections. The module handles Keep-Alive requests and Active Requests through different threads. This keeps the server from being bogged down by keep-alive requests, allowing for faster execution.
Nginx uses an asynchronous, non-blocking, event-driven connection handling algorithm. This means that Nginx spawns worker processes, each of which is capable of handling a large number of connections. This is accomplished because the threads aren’t dedicated to a client, but rather assigned to a specific event (a request for a resource or processeing) when it comes through.
Because of this, a single worker process can service multiple clients without having to generate new threads or processes. This means that it’s resource usage stays around the same even during traffic spikes.
Static and Dynamic Content
Apache handles static content using conventional, file-based methods. The performance of the operations is dependent on the type of MPM that the server is configured to use.
Apache is capable of handling dynamic content by embedding a language processor (For example, a PHP Handler) directly into each of it’s worker instances. This means that Apache doesn’t need to pass the request off to a separate application, but it does mean that there is a bit of overhead on static requests, as the processor is loaded regardless of whether the content is static or dynamic.
Nginx does not have the ability to process dynamic content natively. This means that the request will need to be passed to an external processor, which will then return the rendered content. This can complicate things as an administrator needs to make sure that Nginx can talk to the processor in a way that Nginx can handle (FastCGI, http, etc) and that it can make enough simultaneous connections that it doesn’t need to queue any of the requests.
Because it doesn’t need to load a processor unless it’s needed, Nginx is able to handle static content without as much overhead. This means quicker response times.
Apache includes an option to allow for configuration to be managed on a per-directory basis. This is managed by checking for, and interpreting, hidden files in each directory. These files are known as .htaccess files.
The advantages of this approach are two-fold. Firstly, this allows non-privileged users to control certain aspects of their own config, including redirections, authentication and even caching. Secondly, because it is directory based, Apache needs to check the file every time a request is processed, meaning that changes are processed without having to reload the server config.
Nginx does not provide any mechanism for making configuration changes outside of the main configuration files. This makes it less flexible than the Apache approach, but does have it’s own advantages.
The main advantage is improved performance. Unlike Apache, Nginx doesn’t have to check a directory and all of it’s parent directories for a files every time a request runs. Secondly, because the server administrators are the only ones with control over the web config, non-privileged users can’t add potentially insecure settings to a site on the server.
Combining Both Apache and Nginx
As you can see above, both Apache and Nginx have their own strengths and it can be difficult to identify which server suits your needs more. In some cases, it is possible to leverage the strengths of both servers by using them together.
The most common setup is to run Nginx in front of Apache as a revers proxy. This allows Nginx to handle all of the requests from clients and takes advantage of Nginx’s fast processing and ability to handle a large number of concurrent connections.
If the request is for Static Content, it will be handled directly by Nginx (which is the quicker of the two). Dynamic requests will be passed along to Apache to process.
The advantage of this setup is that it allows Nginx to do what it does best, handling a large number of connections and serving static files, and cuts down on the number of requests that are passed to Apache. Because Apache isn’t generating as many processes, we reduce the blocking that occurs when running just straight Apache.
This configuration also allows for greater physical scaling as it’s easy to add additional backend servers as needed. This also increases this configuration’s resistance to failure and it’s performance.
As you can see, both applications are are powerful, flexible, and capable. Deciding on which one to use will depend mostly on what you need.
Apache, with it’s per-directory config options, is used by shared hosting servers like cPanel as it allows multiple users to manage their own hosting.
Nginx tends to be used for High-Traffic sites with a large number of static files or media streams.
Unfortunately, there’s no one-size-fits-all solution for all situations. When deciding which one to use, try to pick the solution that aligns best with your requirements.