Apache vs Nginx: a practical look

Original author: Justin Ellingwood
  • Transfer
Apache vs Nginx

Introduction


Apache and Nginx are the 2 most widely used open source web servers in the world. Together they serve more than 50% of the traffic on the entire Internet. Both solutions are able to work with a variety of workloads and interact with other applications to implement a complete web stack.

Despite the fact that Apache and Nginx have many similar qualities, they cannot be regarded as completely interchangeable solutions. Each of them has its own advantages and it is important to understand which web server to choose in which situation. This article describes how each of these web servers behaves under different conditions.

general review


Before diving into the differences between Apache and Nginx, let's take a quick look at the background to each of these projects.

Apache


The Apache HTTP Server was developed by Robert McCool in 1995, and since 1999 it has been developed under the supervision of the Apache Software Foundation, the Apache Software Development Fund. Since the HTTP server is the first and most popular foundation project, it is usually called simply Apache.

Web North Apache has been the most popular web server on the Internet since 1996. Due to its popularity with Apache, it has strong documentation and integration with third-party software.

Administrators often choose Apache because of its flexibility, power, and widespread distribution. It can be expanded using a system of dynamically loadable modules and execute programs in a large number of interpreted programming languages ​​without using external software.

Nginx


In 2002, Igor Sysoev began work on Nginx in order to solve the C10K problem - the requirement for software to work with 10 thousand simultaneous connections. The first public release was released in 2004, the goal was achieved thanks to the asynchronous event-driven architecture.

Nginx began to gain popularity since the release due to its light-weight resource utilization and the ability to easily scale to minimal hardware. Nginx is excellent at delivering static content and is designed to transfer dynamic requests to other software designed to handle them.

Administrators often choose Nginx because of its efficient resource consumption and responsiveness under load, as well as because of the ability to use it both as a web server and as a proxy.

Connection Processing Architecture


One of the most significant differences between Apache and Nginx is how they handle connections and respond to various types of traffic.

Apache


Apache provides several multi-processing modules (MPMs), which are responsible for how the client request will be processed. This will allow administrators to define connection processing policies. The following is a list of Apache MPM modules:

  • mpm_prefork - this module creates one process with one thread per request. Each process can process only one connection at a time. While the number of requests is less than the number of processes, this MPM is very fast. However, performance drops rapidly when the number of requests begins to exceed the number of processes, so in most cases this is not the best choice. Each process consumes a significant amount of RAM, so this MPM is difficult to scale. But it can be used along with components that are not designed to work in a multi-threaded environment. For example, PHP is not thread safe, therefore this MPM is recommended to be used as a safe method of working with mod_php.
  • mpm_worker - this module creates processes, each of which can control several threads. Each thread can process one connection. Threads are significantly more efficient than processes, which means mpm_worker scales much better than mpm_prefork. Since there are more threads than processes, this means that a new connection can be immediately processed by a free thread, and not wait until the process is freed.
  • mpm_event - this module is similar to mpm_worker, but is optimized for working with keep-alive connections. When using mpm_worker, the connection will hold the stream regardless of whether the connection is active or keep-alive. Mpm_event allocates separate threads for keep-alive connections and separate threads for active connections. This allows the module not to get bogged down in keep-alive connections, which is necessary for quick work. This module has been marked as stable in Apache version 2.4.

As you can see, Apache offers flexible options for selecting various connection and request processing algorithms.

Nginx


Nginx appeared on the scene later than Apache, for this reason, its developer was better aware of the competitive issues that sites face when scaling. Thanks to this knowledge, Nginx was originally designed based on asynchronous non-blocking event-driven algorithms.

Nginx creates worker processes, each of which can serve thousands of connections. Workers achieve this result thanks to a mechanism based on a fast cycle in which events are checked and processed. The separation of the main work from the processing of compounds allows each worker to do his work and be distracted by the processing of compounds only when a new event has occurred.

Each connection processed by the worker is placed in the event loop along with other connections. In this loop, events are processed asynchronously, allowing tasks to be processed in a non-blocking manner. When the connection closes, it is removed from the loop.

This approach to handling connections allows Nginx to scale incredibly with limited resources. Since the server is single-threaded and it does not create processes for each connection, the use of memory and CPU is relatively even, even at high loads.

Static and dynamic content


Looking at life examples, the main differences between Apache and Nginx are how they handle requests for static and dynamic content.

Apache


Apache can distribute static content using standard file-based methods. The performance of such operations depends on the MPM selected.

Apache can also distribute dynamic content by embedding an interpreter of the desired language in each worker. This allows you to process requests for dynamic content using the web server itself and not rely on external components. Language interpreters can be connected to Apache using dynamically loaded modules.

The ability to process dynamic content with Apache itself simplifies configuration. There is no need to configure interaction with additional software, the dynamic module can be easily disabled in case of changing requirements.

Nginx


Nginx does not have the ability to handle requests for dynamic content. To process requests to PHP or other dynamic content, Nginx must pass the request to an external processor for execution, wait for the response to be generated and receive it. Then the result can be sent to the client.

For administrators, this means that you need to configure the interaction of Nginx with such a processor using one of the protocols that is known to Nginx (http, FastCGI, SCGI, uWSGI, memcache). This can complicate the setup process a bit, especially when you try to predict how many connections to allow, as an additional connection to the processor will be used for each user request.

However, this method has its advantages. Since the interpreter is not built into each worker, the overhead associated with this will only occur when requests for dynamic content are performed. Static content will be returned to the client in a simple way and requests to the interpreter will be executed only when they are needed. Apache can also work in this manner, but then it will deprive it of all the advantages described in the previous section.

Distributed versus Centralized


For administrators, one of the obvious differences between the two web servers is that Apache has the ability to set directory-level configurations.

Apache


Apache has an option that allows you to enable directory-level configuration. If this option is enabled, then Apache will look for configuration directives in directories with content in special hidden files called .htaccess.

Since such configuration files are located in directories with content, Apache is forced to process each request to check whether each component of the requested path contains a file .htaccessand execute directives in the found files. This allows you to decentralize the configuration of the web server, which allows for directory-level modification of URLs (URL rewrite), access restrictions, authorization and authentication, and even caching policies.

Despite the fact that everything described above can be configured in the main Apache configuration file, files .htaccesshave a number of advantages. Firstly, these files are interpreted as soon as they are found on the requested path, which allows you to change the configuration on the fly without restarting the web server. Secondly, it allows non-privileged users to control certain aspects of their own web applications with .htaccess.

This provides an easy way for applications such as content management systems (CMS) to configure their own environment without access to the web server configuration file. This can also be used by shared hosting to maintain control over the main configuration file and give clients control over the configuration of certain directories.

Nginx


Nginx does not interpret files .htaccessand does not provide directory-level configuration mechanism outside the main configuration file. This approach may seem less flexible than with Apache, but it has its advantages.

The main advantage over use .htaccessis improved performance. A typical Apache installation allows you to use files .htaccessin any directory, so the web server is forced to check for the presence of this file in all the parent directories of the requested file with every request . If one or more of these files are found, then all of them must be read and interpreted.

Since Nginx does not allow redefining configs at the directory level, it can process requests faster, because it is enough to make one directory lookup and read one configuration file for each request (it is assumed that the file is found where it should be by agreement).

The second advantage is security. Distributed directory-level configuration in Apache places security responsibility on ordinary users who are unlikely to be able to solve this problem in a quality manner. The fact that the administrator controls the entire server prevents security errors that may occur if users are given access to the configuration.

Keep in mind that you can disable support .htaccessin Apache if the above impressed you.

File and URI Based Interpretation


The way the web server interprets the request and maps it to a resource in the system is another distinguishing feature in these two servers.

Apache


Apache has the ability to interpret the request as a physical resource in the file system or as a URI that requires additional processing. The first type of request uses configuration blocks or , the second, blocks .

Since Apache was originally designed as a web server, it by default interprets requests as resources in the file system. It takes the document root of the web server and completes it with the request part, which follows the host name and port number, to find the requested file. In general, the file system hierarchy presented on the web is available as a document tree.

Apache provides a number of alternatives in case the request does not match the file in the file system. Using blocksThis is a method of working with a URI without mapping to the file system. It is also possible to use regular expressions, which allow you to specify more flexible settings for the entire file system.

Since Apache can operate both with the file system and with webspace, it mainly relies on methods of working with the file system. This can be seen in some decisions in the design of the web server architecture, for example, in the use of files .htaccessfor configuration at the directory level. The Apache documentation does not recommend using URI blocks to restrict access to file system requests.

Nginx


Nginx is designed to operate both as a web server and as a proxy server. For this reason, it works primarily with URIs, translating them, if necessary, into requests to the file system.

This feature can be seen in how configuration files are designed and interpreted for Nginx. There is no way in Nginx to create a configuration for a given directory; instead, it parses a URI.
For example, the main configuration blocks in Nginx are and . The block defines the host that will be serviced, the block is responsible for processing the part of the URI that comes after the host name and port number. Thus, the request is interpreted as a URI, and not as a path in the file system.

In the case of requests to static files, all requests must be mapped to the path in the file system. First, Nginx selects the server and location blocks that will be used to process the request and then combines the document root with the URI, as configured.

These approaches (interpreting the request as paths in the file system and as URIs) may seem similar, but the fact that Nginx treats requests as URIs and not as paths in the file system makes it easier to deal with both the web server role and the role proxy. Nginx is configured to respond to various request patterns. Nginx does not access the file system until it is ready to serve the request, which explains why it does not implement anything similar to files .htaccess.

Modules


Both Apache and Nginx can be expanded using a module system, but the methods for implementing a modular system are fundamentally different.

Apache


Apache's plug-in system allows you to dynamically load and unload plug-ins to meet your needs while your server is running. The Apache core is always available, while modules can be turned on and off to add or remove functionality from the main server.

Apache uses this functionality to solve a wide range of problems. Due to the maturity of the platform, there are a huge number of modules that can change the key features of the server, for example, the module mod_phpallows you to include a PHP interpreter in each worker.

Using modules is not limited to processing dynamic queries. Among other features of the modules: changing URLs (URL rewrite), client authentication, server protection, logging, caching, compression, proxing, limiting the frequency of requests, encryption. Dynamic modules can greatly expand the functionality of the kernel.

Nginx


Nginx also has a module system, but it is very different from the approach used in Apache. In Nginx, modules are not loaded dynamically, but must be selected and compiled with the server core.

For many users, for this reason, Nginx seems less flexible. This is especially true for users who have little experience building applications manually and prefer to use package management systems. Distribution developers usually strive to create packages for all commonly used modules, but if you need some kind of non-standard module you will have to compile it from the sources yourself.

Nevertheless, the modules in Nginx are very useful and in demand, you can determine what you want from the server and include only those modules that you need. Some users consider this approach more secure since arbitrary modules cannot be connected to the server.

Nginx modules implement the same features as Apache modules: proxying, data compression, limiting the frequency of requests, logging, URL modification, geolocation, authentication, encryption, streaming, mail functions.

Support, Compatibility, Ecosystem, and Documentation


In the process of using the application, the ecosystem created around it and the ability to receive support are important.

Apache


Since Apache has been popular for such a long time, it has no problems with support. You can easily find a large amount of documentation from both Apache developers and third-party authors. This documentation covers all possible Apache usage scenarios, including interactions with other applications.

There are many tools and web projects bundled with tools to launch themselves from under Apache. This applies both to the projects themselves and to the package management systems.

In general, Apache will have more support in third-party projects, simply because it has been available on the market for a long time. Administrators also usually have more experience with Apache, since most people start with shared hosting where Apache is more popular because of file support..htaccess.

Nginx


Nginx is commonly used where performance requirements are high and in some areas it is still catching up.

In the past, it was difficult to find sane support for this web server in English, since in the early stages development and documentation were conducted in Russian. Along with the growing interest in the project, the documentation was translated into English and now you can find enough documentation from the developers of the web server and from third-party authors.

Third-party software developers are also starting to support working with Nginx, and some of them already offer user-selectable configs for working with either Apache or Nginx. And even without the application supporting the work with Nginx, it is not difficult to write your own config for integrating the application with Nginx.

Sharing Apache and Nginx


After you familiarize yourself with the pros and cons of Apache and Nginx, you should have an idea of ​​which server is more suitable for your tasks. However, you can achieve better results using both servers together.

A common use case is to place Nginx before Apache as a reverse proxy. In this configuration, Nginx is called the frontend, and Apache is called the backend. With this approach, Nginx will serve all incoming client requests and we will get a win because of its ability to handle many competitive requests.

Nginx will independently serve static content, and for dynamic content, for example, requests to PHP pages, it will transfer a request to Apache, which will render the page, return it to Nginx, and it will in turn transfer it to the user.

This configuration is very popular, Nginx is used in it to sort requests. It processes itself the requests that Apache can and transfers only requests that it cannot service itself, thus reducing the load on Apache.

This configuration allows you to horizontally scale the application: you can install several backend servers for one frontend and Nginx will distribute the load between them, thereby increasing the fault tolerance of the application.

Conclusion


As you can see, both Apache and Nginx are powerful, flexible, and functional tools. In order to choose a server for your tasks, you need to determine the requirements for it and conduct tests on all possible patterns of using your application.

There are significant differences between these projects that can affect the performance, capabilities, and implementation time required to implement and launch each solution. The choice is a series of compromises and do not neglect the tests. In the end, there is no one universal web server for all possible tasks, so it is important to find a solution that is most suitable for your tasks and goals.

Also popular now: