NGINX vs. Apache

The first version of the Apache HTTP server appeared in 1995. Today, more than 20 years later, the software continues to reign as the king of web servers – but not without com­pet­i­tion. In par­tic­u­lar, the Russian web server NGINX (pro­nounced “Engine-X”), also an open source project, is gaining market share – and at breakneck speed. What’s most harmful for the Apache Found­a­tion: Most of the websites that do well in the Alexa rankings today are already delivered via NGINX. You can see regularly-updated web server usage stat­ist­ics from W3Techs. It’s not just Russian internet giants, such as the search engines Ramblex and Yandex, the e-mail service Mail.RU, or the social network VK that rely on the light­weight web server; in­ter­na­tion­al providers such as Dropbox, Netflix, WordPress, and FastMail.com also use NGINX to improve the per­form­ance of their services. Will the Apache HTTP server be outdated soon?

The web servers Apache and NGINX are based on fun­da­ment­ally different software ar­chi­tec­tures. Varying concepts are found in regard to con­nec­tion man­age­ment, con­fig­ur­a­tion, the in­ter­pret­a­tion of client requests, and the handling of static and dynamic web content.

Depending on which module is used, Apache solves the con­cur­rency problem (the sim­ul­tan­eous answer of multiple client requests) by adding either ad­di­tion­al processes or threads. Both solution strategies involve ad­di­tion­al resource expense. This becomes a limiting factor for the scaling of an Apache server.

The enormous resource appetite of the one-process-per-con­nec­tion approach results from the fact that a separate runtime en­vir­on­ment must be provided for each ad­di­tion­al process. This requires the al­loc­a­tion of CPU time and separate storage. Each Apache module that’s available to a worker process also has to be loaded sep­ar­ately for each process. Threads, on the other hand, share an execution en­vir­on­ment (the program) and address space in the memory. The overhead of ad­di­tion­al threads is therefore con­sid­er­ably less than that of processes. But multi-threading is com­pu­ta­tion-intensive, too, when context switches are used.

A context switch means the process of switching from one process or thread to another in a system. To do this, the context of the ter­min­ated process or thread must be saved and the context of the new process or thread must be created or restored. This is a time-intensive ad­min­is­trat­ive process, in which the CPU register as well as various tables and lists need to be loaded and saved.

The mpm_event module has an event mechanism available for the Apache HTTP server that transfers the pro­cessing of an incoming con­nec­tion to a listener thread. This makes it possible to terminate con­nec­tions that are no longer required (including keep-alive con­nec­tions) and so reduce resource con­sump­tion. This doesn’t solve the problem of com­pu­ta­tion-intensive context change that occurs when the listener thread passes requests to separate worker threads via its held con­nec­tions, though.

By contrast, NGINX’s event-based ar­chi­tec­ture realises con­cur­rency without requiring an ad­di­tion­al process or threat for each new con­nec­tion. A single NGINX process can handle thousands of HTTP con­nec­tions at the same time. This is achieved by means of a loop mechanism called the event loop. This makes it possible to asyn­chron­ously process client requests within a threat.

All worker processes started by the NGINX master process during con­fig­ur­a­tion share a set of listener sockets. Instead of starting a new process of thread for each incoming con­nec­tion, an event loop is run in every worker process that enables the asyn­chron­ous handling of thousands of con­nec­tions within one thread without blocking the process. To do this, the worker processes at the listener sockets con­tinu­ously listen for events triggered by incoming con­nec­tions, accept them, and execute read and write processes on the socket during the pro­cessing of HTTP requests.

NGINX doesn’t have its own mechanism available for the dis­tri­bu­tion of con­nec­tions to worker processes. Instead, core functions of the operating system are used. Schemes on how to handle incoming requests are provided by separate state machines for HTTP, raw TCP, SMTP, IMAP, and POP3.

In general, NGINX can be described as an event handler which receives in­form­a­tion about events from the core and tells the operating system how to handle the as­so­ci­ated tasks. The asyn­chron­ous pro­cessing of tasks with the event loop is based on even no­ti­fic­a­tions, callbacks, and timers. These mech­an­isms make it possible for a worker process to delegate one operation after the other to the operating system without having to wait idly for the result of an operation or for client programs to respond. NGINX functions as an or­ches­trat­or for the operating system, and takes over the reading and writing of bytes.

This type of con­nec­tion man­age­ment only creates a minimal overhead for ad­di­tion­al con­nec­tions. All that’s needed is an ad­di­tion­al file descriptor (FD) and a minimum of extra memory in the worker process. Com­pu­ta­tion-intensive context switches, on the other hand, only occur if no further events occur within an event loop. This ef­fi­ciency in the pro­cessing of requests over a variety of con­nec­tions makes NGINX the ideal load dis­trib­ut­or for highly fre­quen­ted websites such as WordPress.com.

When it comes to dynamic web content, NGINX also follows a different strategy than the Apache HTTP server.

In principle: To be able to deliver dynamic content, a web server needs to have access to an in­ter­pret­er that’s capable of pro­cessing a required pro­gram­ming language, such as PHP, Perl, Python, or Ruby. Apache has various modules available, including mod_php, mod_perl, mod_python, or mod_ruby, which make it possible to load the cor­res­pond­ing in­ter­pret­er directly into the web server. As a result, Apache itself is equipped with the ability to process dynamic web content created with the cor­res­pond­ing pro­gram­ming language. Functions for the pre­par­a­tion of static content are already im­ple­men­ted with the above-mentioned MPM module.

NGINX, on the other hand, only offers mech­an­isms for de­liv­er­ing static web content. The pre­par­a­tion of dynamic content is out­sourced to a spe­cial­ised ap­plic­a­tion server. In this case, NGINX only functions as a proxy between the client program and upstream server. The com­mu­nic­a­tion takes place via protocols like HTTP, FastCGI, SCGI, uWSGI, and Memcached. Possible ap­plic­a­tion servers for de­liv­er­ing dynamic content are offered by WebSphere, JBoss, or Tomcat. The Apache HTTP server can also be used for this purpose.

Both strategies for de­liv­er­ing static and dynamic content come with their benefits and drawbacks. A module like mod_php allows the web server to execute PHP code itself. A separate ap­plic­a­tion server isn’t needed. This makes the ad­min­is­tra­tion of dynamic website very simple. But the in­ter­pret­er modules for dynamic pro­gram­ming languages have to be loaded sep­ar­ately into each worker process that’s re­spons­ible for de­liv­er­ing content. With a large number of worker processes, this is as­so­ci­ated with a sig­ni­fic­ant overhead. This overhead is reduced by NGINX, since the out­sourced in­ter­pret­er is only called upon when required.

While NGINX is set to interact with an out­sourced in­ter­pret­er, Apache users can choose either of these two strategies. Apache can also be placed in front of an ap­plic­a­tion server that’s used to interpret dynamic web content. Usually, the protocol FastCGI is used for this. A cor­res­pond­ing interface can be loaded with the module mod_proxy_fcgi.

To be able to sat­is­fact­or­ily answer requests from client programs (for example, web browsers or e-mail programs), a server needs to determine which resource is requested and where it’s found based on the request.

The Apache HTTP server was designed as a web server. On the other hand, NGINX offers web as well as proxy server functions. This dif­fer­ence in focus is reflected in the way that the software in­ter­prets client requests and allocated resources on the server.

Apache HTTP server and NGINX both have mech­an­isms that allow incoming requests to either be in­ter­preted as physical resources in the file system or as URIs (Uniform Resource In­den­ti­fi­er). But while Apache works based on files by default, URI-based request pro­cessing is more prominent with NGINX.

If the Apache HTTP server receives a client request, it assumes by default that a par­tic­u­lar resource is to be retrieved from the server’s file system. Since Apache uses Vir­tu­al­Hosts to provide different web content on the same server under different host names, IP addresses, or port numbers, it must first determine which Vir­tu­al­Host the request is referring to. To do this, the web server matches the host name, IP address, and port number at the beginning of the request URI with the Vir­tu­al­Hosts defined in the main con­fig­ur­a­tion file httpd.conf.

The following code example shows an Apache con­fig­ur­a­tion where the two domains www.example.com and www.other-example.com are operated under the same IP address:

The asterisk (*) serves as a place­hold­er for an IP address. Apache decides which Doc­u­ment­Root (the starting directory of a web project) the requested resource will be searched in by comparing the host name contained in the request with the Server­Name directive.

If Apache finds the desired server, then the request URI is mapped to the file system of the server by default. Apache uses the path spe­cific­a­tion contained in the URI for this. In com­bin­a­tion with the Doc­u­ment­Root, this amounts to the resource path.

For a request with the request URI "http://www.example.org:80/public_html/images/logo.gif", Apache would search for the desired resource under the following file path (based on the example above):

Apache also matches the request URI with optional file and directory blocks in the con­fig­ur­a­tion. This makes it possible to define special in­struc­tions for requests that lead to the selected files or dir­ect­or­ies (including sub­dir­ect­or­ies).

In the following example, special in­struc­tions are defined for the directory public_html/images and the file private.html:

In addition to this standard procedure for in­ter­pret­ing client requests, Apache offers the alias directive, which allows you to specify an alternate directory to search for the requested resource instead of the Doc­u­ment­Root. With mod_rewrite, the Apache HTTP server also provides a module that allows users to rewrite or forward URLs.

The request URI isn’t matched with the location blocks within a server block until the requested server has been found. For this, NGINX reads the specified location blocks and searches for the location that best matches the request URI. Each location block contains specific in­struc­tions that tell NGINX how the cor­res­pond­ing request is to be processed.

Locations can be set to be in­ter­preted as a prefix for a path, as an exact match, or as a regular ex­pres­sion (RegEx). In the syntax of the server con­fig­ur­a­tion, the following modifiers are used:

The following example shows three location blocks which display how the in­form­a­tion for the domains 'example.org' and 'www.example.org' are to be processed:

Based on a client request with the request URI 'http://www.example.org:80/logo.gif', NGINX would proceed as follows to interpret the requests and deliver the desired resource:

First, NGINX de­term­ines the specific prefix location. To do this, the web server reads all locations with modifiers in sequence and stops at the first location that matches the request. Then all locations are read out that are marked with the RegEx modifier (~). The first match is also used here. If no matching RegEx location is found, then the web server uses the pre­vi­ously de­term­ined prefix location as a fallback.

The request URI 'http://www.example.org:80/logo.gif' matches, for example, with the prefix location / as well as with the regular ex­pres­sion \.(gif|jpg|png)$. NGINX would therefore map the request in com­bin­a­tion with the root to the file path /data/www/logo.gif and deliver the cor­res­pond­ing resource to the client. The expired header indicates when an answer is con­sidered obsolete – in the current example, it’s after 30 days: expires 30d.

The request for the PHP page with the URI 'http://www.example.org:80/index.php' also matches the prefix location / and the RegEx location ~ \.php$, which receives pref­er­en­tial treatment. NGINX forwards the request to a FastCGI server that listens on localhost:9000 and is re­spons­ible for the pro­cessing of dynamic web content. The fastcgi_param directive sets the FastCGI parameter SCRIPT_FILENAME to /data/www/index.php. Then the file is run on the upstream server. The variable $document_root cor­res­ponds to the root directive, and the variable $fastcgi_script_name cor­res­ponds to the part of the URI that follows the host name and port number: /index.php.

This seemingly com­plic­ated procedure for in­ter­pret­ing client requests is due to the different fields of ap­plic­a­tion in which NGINX is used. As opposed to the primarily file-based approach of the Apache HTTP server, the URI-based request in­ter­pret­a­tion enables more flex­ib­il­ity with the pro­cessing of different request patterns. This is required, for example, when NGINX is being run as a proxy or mail-proxy server instead of as a web server.

NGINX is said to have a tre­mend­ous speed advantage over the Apache HTTP server when it comes to de­liv­er­ing static web content. This is partly due to dif­fer­ence in con­fig­ur­a­tion. In addition to the main con­fig­ur­a­tion file httpd.conf, the Apache web server gives ad­min­is­trat­ors the option of directory-level man­age­ment. This uses .htaccess files. In principle, these de­cent­ral­ised con­fig­ur­a­tion files can be im­ple­men­ted in any server directory that you want. In­struc­tions, which are defined in an .htaccess, indicate which directory the con­fig­ur­a­tion file contains as well as its sub­dir­ect­or­ies. In practice, .htaccess files are used to restrict directory access to specific user groups, set up password pro­tec­tion, or define reg­u­la­tions for directory browsing, error messages, for­ward­ing, or alternate content. Note that this can also be con­figured centrally in the httpd.conf file. But .htaccess becomes relevant in web hosting models such as shared hosting, where access to the main con­fig­ur­a­tion file is reserved for the hosting service provider. The de­cent­ral­ised con­fig­ur­a­tion via .htaccess makes it possible to allow users to permit ad­min­is­tra­tion for par­tic­u­lar areas of the server file system – for example, for selected project dir­ect­or­ies – without giving access to the main con­fig­ur­a­tion. Changes also take effect im­me­di­ately without requiring a restart. NGINX, on the other hand, only offers central con­fig­ur­a­tion pos­sib­il­it­ies. All in­struc­tions are defined in the nginx.conf file. With access to this file, a user gains control over the entire server. In contrast to apache, the ad­min­is­trat­ive access is not limited to selected dir­ect­or­ies. This has ad­vant­ages as well as dis­ad­vant­ages. The central con­fig­ur­a­tion of NGINX is less flexible than the concept used by the Apache HTTP server, but it offers a clear security advantage: Changes to the con­fig­ur­a­tion of the web server can only be made by users who are given root per­mis­sions. More important than the security argument, though, is the per­form­ance dis­ad­vant­age of using a de­cent­ral­ised con­fig­ur­a­tion via .htaccess. The developer has already re­com­men­ded in the Apache HTTP server doc­u­ment­a­tion re­frain­ing from using .htaccess if access to httpd.conf is possible. The reason for this is the procedure that Apache uses to read and interpret con­fig­ur­a­tion files. As pre­vi­ously mentioned, Apache follows a file-based scheme for answering client requests by default. Since the Apache ar­chi­tec­ture allows a de­cent­ral­ised con­fig­ur­a­tion, the web server searches through every directory along the file path on the way to the requested resource for an .htaccess file. All con­fig­ur­a­tion files that it passes are read and in­ter­preted – a process that sig­ni­fic­antly slows down the web server.

Users who want to disable or limit the de­cent­ral­ised con­fig­ur­a­tion on Apache can use the directive Al­lo­wOver­ride in the directory blocks of the main con­fig­ur­a­tion file httpd.conf and set them to None. This allows the web server to ignore all .htaccess files in the cor­res­pond­ing con­figured dir­ect­or­ies.

The example con­fig­ur­a­tion indicates to the web server that all .htaccess files for the host example.com should be ignored.

Both web servers in our com­par­is­on run on a modular system in which the core system can be extended with ad­di­tion­al com­pon­ents as needed. Up to version 1.9.10, though, NGINX pursued a fun­da­ment­ally different strategy for dealing with modules than the competing product. The Apache HTTP server has two available options for extending the core software. Modules can either be compiled into the Apache binary files during de­vel­op­ment or they can be loaded dy­nam­ic­ally during runtime. There are three cat­egor­ies of Apache modules:

• Basic modules: The Apache basic modules include all com­pon­ents that provide the core func­tion­al­it­ies of the web server.

• Extension modules: These ex­ten­sions are modules of the Apache Found­a­tion that are included as part of the Apache dis­tri­bu­tion. An overview of all modules contained in the Apache 2.4 standard in­stall­a­tion is available in the Apache doc­u­ment­a­tion.

• Third-party modules: These modules are not from the Apache Found­a­tion, but instead provided by external service providers or in­de­pend­ent pro­gram­mers.

NGINX, on the other hand, limited the mod­u­lar­ity for a long time to static extension com­pon­ents that had to be compiled into the binary file of the software core. This type of software extension sig­ni­fic­antly re­stric­ted the flex­ib­il­ity of the web server, es­pe­cially for users who weren’t used to managing their own software com­pon­ents without the package manager of the re­spect­ive dis­tri­bu­tion. The de­vel­op­ment team made massive im­prove­ments in this respect: Since version 1.9.11 (Release 09 Feb 2016), NGINX supports mech­an­isms that make it possible to convert static modules to dynamic so that they can be loaded via the con­fig­ur­a­tion file during runtime. In both cases, the module API of the server is used. Please note that not all NGINX modules can be converted into dynamic modules. Modules that patch the source code of the server software shouldn’t by dy­nam­ic­ally loaded. NGINX also limits by default the number of dynamic modules that can be loaded at the same time to 128. To increase this limit, set the NGX_MAX_DYNAMIC_MODULES constant to the desired value in the NGINX source code. In addition to the official modules of the NGINX doc­u­ment­a­tion, various third-party modules are available to users.

• NGINX extension modules
• Third-party modules for NGINX

Both software projects are well doc­u­mented and provide users with first-hand in­form­a­tion about wikis and blogs.

• Apache HTTP server: Wiki
• NGINX: Wiki

While the NGINX doc­u­ment­a­tion is only available in English and Russian, the Apache project has in­form­a­tion material in various language versions. Some of these are outdated, though, so a look at the English doc­u­ment­a­tion is necessary here too. Users can get help with problems for both open source projects through the community. For this purpose, mailing lists function as dis­cus­sion forums.

• Apache HTTP server: Mailing lists
• NGINX: Mailing lists

Trans­par­ent release plans and roadmaps give users the pos­sib­il­ity to adapt for future de­vel­op­ments. Software errors and security gaps for both projects are processed and recorded in a public bug report.

• Apache HTTP server: Bug report
• NGINX: Bug report

In addition to the NGINX open source project, Nginx, Inc. also offers the com­mer­cial product NGINX Plus. For an annual usage fee, users receive ad­di­tion­al functions as well as pro­fes­sion­al support from the man­u­fac­turer. A com­par­is­on matrix of both programs is found on the NGINX website. A com­mer­cial edition of the Apache HTTP serve doesn’t exist. Paid support services can be obtained from various third parties, though.

The Apache HTTP server has dominated the World Wide Web for more than two decades and, due to its market share, is still con­sidered the de facto standard for preparing web content. NGINX also has a 15-year success story to look back on. Both web servers are char­ac­ter­ised by wide platform support. While Apache is re­com­men­ded for all unix-like operating systems as well as for Windows, the NGINX doc­u­ment­a­tion cites the following systems as tested: FreeBSD, Linux, Solaris, IBM AIX, HP-UX, macOS, and Windows. As a standard server, Apache features broad com­pat­ib­il­ity with third-party projects. All relevant web standards can be in­teg­rated using modules. Most players on the web are also familiar with the concepts of Apache. Ad­min­is­trat­ors and web de­velopers usually implement their first projects on af­ford­able shared hosting platforms. These, in turn, are mostly based on Apache, and its pos­sib­il­ity of de­cent­ral­ised con­fig­ur­a­tion via .htaccess. The Apache HTTP server is also part of various open source program packages for de­vel­op­ment and software tests, such as XAMPP or AMPPS. A large ecosystem of modules is also available to NGINX users. In addition, the de­vel­op­ment team cul­tiv­ates part­ner­ships with various open source and pro­pri­et­ary software projects, as well as with in­fra­struc­ture service providers such as Amazon Web Services, Windows Azure, and HP.

Despite their large dif­fer­ences in software ar­chi­tec­ture, both web servers offer similar functions. Apache and NGINX are used in com­par­able scenarios, but use their own strategies and concepts to meet re­quire­ments. The following table compares both software projects based on their central features and shows their sim­il­ar­it­ies and dif­fer­ences.

With Apache and NGINX, users have two stable, secure open source projects available to them. But after the com­par­is­on, neither of the web servers is the clear winner. Both projects are based on fun­da­ment­ally different design decisions that can be either an advantage or a dis­ad­vant­age, depending on how the software is used.

The Apache HTTP server offers an immense rep­er­toire of modules which, together with the flexible con­fig­ur­a­tion options, open numerous fields of ap­plic­a­tion for the software. The web server can also be a standard software for shared hosting scenarios and will continue to stand its ground in its field against light­weight web servers such as NGINX. The ability to directly integrate in­ter­pret­ers for pro­gram­ming languages such as PHP, Perl, Python, or Ruby into the web server using modules allows for dynamic web content to be delivered without the use of a separate ap­plic­a­tion server. This makes the Apache HTTP server a com­fort­able solution for small and medium-sized websites where content is dy­nam­ic­ally created during retrieval.

NGINX, on the other hand, doesn’t offer any pos­sib­il­it­ies to natively process dynamic web content or integrate cor­res­pond­ing in­ter­pret­ers via modules. A separate ap­plic­a­tion server is always required. This may seem like un­ne­ces­sary extra effort for small to medium-sized websites. However, such an ar­chi­tec­ture shows its strength for large web projects and in­creas­ing traffic volumes.

In general, NGINX is used as a load balancer in front of a group of ap­plic­a­tion servers. The load balancer accepts incoming requests and decides, depending on the type of request, whether it needs to be forwarded to a spe­cial­ised server in the back­ground. Static web content is delivered directly by NGINX. If a client requests dynamic content, then the load balancer gives the request to a dedicated ap­plic­a­tion server. This in­ter­prets the pro­gram­ming language, assembles the requested content into a webpage, and gives it back to the load balancer, which delivers it to the client. In this way, high traffic volumes can ef­fect­ively be managed.

NGINX caches already deliver content for a certain amount of time, so that newly requested dynamic content can be delivered directly by the load balancer without NGINX having to access an ap­plic­a­tion server again.

The out­sourcing of in­ter­pret­ers to one or multiple separate backend servers has the advantage that the server network can easily be scaled if ad­di­tion­al backend servers need to be added, or systems that are no longer necessary can be switched off. In practice, many users rely on a com­bin­a­tion of NGINX and Apache for such a setup, and use the strengths of both servers.