Apache and Nginx: what, when and why?

apache and nginx

Apache and Nginx are the two most popular open-source web servers in the world. Together they serve over half of the traffic on the internet. They also run on the majority of the most popular websites on the Internet. You can see the stats for yourself. While Apache and Nginx share many qualities, they are very different in some areas. Tach excels in its own way and has its own usage scenarios if we can say so.
Perhaps, the biggest difference between Apache and Nginx is the actual way they handle connections and traffic and respond to different traffic conditions. You can see that Apache provides a variety of multi-processing modules MPMs, as we know them. That are mpm_prefork, mpm_worker, mpm_event, and we won't go deep into this. These 3 modules are basically 3 types of requests, handling algorithms, each suitable for different server needs or load scenarios.
MPMs provide a flexible architecture for choosing different connections and request-handling algorithms. But the flexibility for which Apache is famous comes at a cost of resource consumption. And we know that in some scenarios or working conditions Apache can «eat your server for breakfast».
What about Nginx: it basically designed to use an asynchronous non-blocking event-driven connection candling algorithm. It pounds worker processes, each of which can handle thousands of connections. Such a connection processing model allows Nginx to scale very fast and wide with limited resources. So you can use it on low-power systems or on systems, which operate under heavy loads.

Static and dynamic content

Apache handles static content using its conventional file-based methods. It can also process dynamics within the web server itself without having to rely on any external components, so it can handle your scripts itself. And Nginx can't process dynamic content itself: it passes the content, for example, PHP scripts, to an external processor for execution and waits for the rendered content to be sent back.

Distributed or centralized configuration

Apache allows additional configuration on a per-directory basis by interpreting directives in .htaccess files. This architecture makes it possible to allow non-privileged users to control certain aspects of their websites without granting them permission to edit the main config file.
Nginx on the other hand has a bit of a downside because it doesn't provide any mechanism for per-directory configuration. But I should note that this downside pays in increased performance cause by not allowing directory config overwrites, Nginx can serve requests faster, way faster! It doesn't need to search to .htaccess files with them and interpret for that every request made by the user.

Interpretation of the requests and their mapping to actual resources on the system

Apache provides the ability to operate on both the underlying file system and the webspace. It leans heavily towards file system methods. Nginx was created to be both a web server and a proxy server and due to the architecture required for these 2 roles it works primarily with URIs, translating to the file system when necessary. You can see that in some of the ways how Nginx is constructing configuration files.
Nginx doesn't provide a mechanism or specifying configuration for a file system directory and instead passes the URI itself. This may seem similar, but passing requests similarly as URIs instead of file system locations allows Nginx to more easily function in both web and proxy server roles. Nginx is configured simply by laying out how to respond to different request patterns. Nginx doesn't check the file system until it is ready to serve the request which explains why it doesn't implement any form of .htaccess files.


Both Nginx and Apache are extensible through module systems. But the way that they work differs a lot. A patches module system allows you to dynamically load or unload modules to satisfy your needs during the course of running the server. The Apache Core is always present while modules can be turned on / off adding or removing additional functionality and hooking into the main server. On the other hand, Nginx modules must be selected and compiled into the core software, and they are not dynamically loadable.
Nginx modules are still very useful though and they allow you to dictate what you want out from your server by only including the functionality you intend to use. Some users also may consider this more secure and arbitrary components cannot be hooked into the server. But note that Nginx modules allow many of the same capabilities as Apache modules.

Apache and Nginx: what to choose?

After going over the benefits and limitations of both Apache and Nginx you may already have an idea of which server better fits your needs. But many administrators find that it is possible to leverage each server's strength by using them together. You can place Nginx «in front» of Apache as a server proxy. This will allow Nginx to handle all requests from clients. This takes advantage of Nginx fast processing speed and ability to handle a large number of connections simultaneously.
For static content, which Nginx excels at, the files will be served quickly and directly to the client. For dynamic content, on the other hand, for instance, PHP files Nginx will proxy the request to Apache which can then process the results and return the rendered page. Nginx can then pass that content back to the client. This model allows you to have a very functional web server and to serve your client's large volume of users very fast.

Our best practice solution

Our experience and knowledge show that in most of the cases Nginx shows better flexibility, performance power, and some other metrics, and characteristics. To prove our vision we attached some graphs and metrics from our internal monitoring tool, where you’re able to see the loads on one of our client's servers. Below you can see the CPU load on the x4 core processor with hyper-threading.


You can overview the number of requests per minute, which the same Nginx web server handles below. We'd like to state, that the client also has a backend on this server.


On the graph below you can see one more example of another server with traffic floating on it. As you can see it's 86000 unique connections at one time that the server handles perfectly!


The choice of which technology to use or not - is yours. We’re able to help you with the right choice and reason for it. You choose - we implement.
Live long and prosper!