Apache vs. Nginx A Definitive Comparison

Apache and Nginx are the two most powerful and prevalent web servers out there. According to W3Techs, these two web servers collectively power over 65% of websites on the internet. Both solutions are open-source, stable, and capable of running large-scale applications. However, there are some unique characteristics of each that may make you choose one over the other.

In the following article, we’ll share a detailed comparison of Apache and Nginx. We’ll look at their contrasting architectures, and see how they fare against each other in different departments, such as speed, ease of use, scalability, security, and caching.

What is Apache web server?

Web servers store web content and return it on receiving HTTP requests. Apache is one of the oldest web server technologies. It is process-driven, meaning that it creates a new process for each new request.

Apache was launched in 1995 and remains relevant to this day. It has been maintained by the Apache Software Foundation since 1999. It’s easy to install, configure, and extend. It can run on multiple platforms and operating systems, integrates well with other software, and is supported by a large developer community.

Apache played a pivotal role in the growth of the World Wide Web, and for decades, it stayed the undisputed platform of choice. One of the main reasons for its popularity is its dynamically loadable module system, which makes it easy to customize and extend the server.

What is Nginx?

Nginx is an open-source web server, like Apache (although there is also a paid version, known as Nginx Plus). The notable difference is that Nginx is event-driven rather than process-driven. This means that, with Nginx, performance does not slow down as events increase.

The first public release of Nginx dates to 2004. Its major design goal was to solve the C10K problem, which was a scalability issue that prevented web servers (even Apache) from handling more than 10,000 concurrent requests. Nginx solved this problem by using an event-based approach to handle requests (more on this in the next section).

Nginx was originally developed to be used as a reverse proxy or load balancer for Apache, so that Apache could scale at the pace of the growing web. However, owing to its inherently superior architecture and request processing ability, people started using it as a web server. Today, it has not only evolved into a full-fledged, ready-to-deploy web server, but also surpassed Apache in terms of adoption.

Apache vs. Nginx

Architecture and connection handling

The architectures of Apache and Nginx are fundamentally different in the way they handle connections and process requests.

Apache

Apache relies on a process-based architecture to serve requests. It contains several built-in modules, known as multi-processing modules (MPMs), which allow administrators to choose their preferred connection-handling algorithm.

For example, the mpm_prefork module spawns a child process for every new request. This model is not sustainable because the operating system allocates separate memory resources and an address space for each process, leading to a lot of memory overhead. In peak hours, you risk memory exhaustion, which can make a server unresponsive to new requests, or even crash.

The mpm_worker and mpm_event modules can be used to deploy a multi-threaded web server. They are more efficient than mpm_prefork because they create different worker threads for every process, and thus scale better, because threads hold a much smaller memory footprint than processes. However, even these modules can’t rival the performance and scalability delivered by Nginx’s event-driven architecture.

Nginx

Nginx takes a radically different approach when handling requests. It is event-driven and asynchronous, which means that it can process multiple requests simultaneously. Instead of associating a process or a thread with each request, it spawns multiple worker processes to handle all incoming requests.

Whenever a new request is received, the Nginx engine fires a new event. The worker processes are responsible for handling events and placing them within the event loop. The server asynchronously processes each event in the event loop and removes it when the connection closes.

Each worker process is single-threaded, and the number of worker processes doesn’t grow as the number of requests increases. Moreover, the worker processes are only activated when a new event is fired, and they off-load the actual event processing to the server. This approach enables Nginx to have uniform CPU and memory usage, and scale better than Apache, with fewer resources.

Speed

Nginx’s event-driven architecture is intrinsically faster than Apache’s process-based architecture, especially during peak hours and longer runs. There are several benchmarks to back this claim.

For instance, the LiteSpeed team used HTTP/2 and HTTP/1.1 implementations of Apache and Nginx to compare their performance when loading WordPress. For HTTP/2, Nginx was able to serve over 6,000 requests per second, whereas Apache could only serve 826. Nginx was able to deliver a speed of 24.5MB/s, whereas Apache could only manage 3.08MB/s.

The HTTP/1.1 test results followed a similar trend. Nginx catered to 5,730 requests per second, whereas Apache responded to only 1,000 requests per second. Nginx loaded data at a speed of 24.15MB/s, whereas Apache was clocked at 4.09MB/s.

Configurations

Configurability is a top concern when choosing a web server. Administrators and developers prefer a web server that is easy to configure and extend. Let’s see how Apache and Nginx compare in this department.

Apache

Apache takes a decentralized approach to configuration. Administrators can define directory-specific configurations by creating a .htaccess file in any directory on the server. These files allow you to implement several features via directives, including custom error messages, caching, indexing, password protection, and redirects.

.htaccess files are processed for all elements of a request path. The directives defined in the file apply to the directory and all its sub-directories. They are great for allowing non-privileged users to configure certain parts of the server, without giving them access to the main configuration file.

With that said, it’s recommended to only use .htaccess files when you either don’t have access to the main configuration file, or want to apply configuration on a per-directory basis. If you choose not to use them, consider disabling .htaccess processing for better performance. Lastly, ensure that the directives added to your .htaccess files don’t create any security or performance issues with the server.

Nginx

Configuration in Nginx is centralized – i.e., you can configure it using the main configuration file. It neither supports .htaccess files, nor offers any way to define per-directory configurations. The configuration file allows you to tweak the server name, number of worker connections, port, log file location, and more.

Even though a centralized approach may seem limiting at first, it has several advantages, the first being better performance. Unlike Apache, Nginx doesn’t have to check and process .htaccess files for each request. Moreover, having a centralized configuration file significantly reduces your attack surface and chances of human error.

Caching

Caching can significantly decrease the load on the server, thereby increasing overall performance and throughput.

Apache

Apache offers several loadable modules for caching. The mod_cache module is an implementation of the HTTP content caching filter, which can be used to serve both static and dynamic content. Using different module directives, you can define default cache expiry, disable cache for specific URLs, ignore query strings while caching, and more.

The mod_cache_disk module allows you to store cached responses to disk, including the bodies and the headers. You can also cache the most frequently used files using the mod_file_cache module. Via the htcacheclean module, you can keep a cache’s size in check and clean it when necessary.

Nginx

Nginx has several directives that make it easy to enable caching and set different caching policies. For example, you can use the proxy_cache_path directive to enable caching, set the path of the cache, and tweak configurable parameters.

Other directives, like proxy_cache, proxy_cache_background_update, proxy_cache_bypass, proxy_cache_max_range_offset, proxy_cache_key, and proxy_cache_methods allow you to configure different conditions and schemes for caching.

For example, you can specify which requests to cache or bypass. You can choose when to refresh an expired cache item. You can also define the number of requests after which an entry should be cached, or flush the cache at any time.

Security

Security is another top consideration when choosing a web server.

Apache

Apache has a loadable module, mod_security, which implements all rules of the ModSecurity Core Rule Set (CRS). It protects your web application against the most common attacks, including cross-site scripting, SQL injection, broken access control, and sensitive data exposure. You can add built-in or custom security rules using the default mod_security configuration file.

Apache also has several configuration parameters that can alleviate security risks. For example, you can set the Directory tag in your configuration file to “Require all denied” to disable default access to your file system. Or you can use the MaxRequestWorkers directive to set a limit on the maximum number of active connections.

Over the years, Apache has proven to be secure by design, with only a few critical vulnerabilities and bugs ever reported. Its developer community is also vigilant in detecting and fixing any potential bugs or security holes.

Nginx

The Nginx ModSecurity Web Application Firewall (WAF) also implements all rules of the ModSecurity CRS, and can be loaded as a native module. Just like Apache, you can add default and custom rules to a Nginx installation using the ModSecurity configuration file.

Additionally, the official Nginx documentation lists several security controls to harden the web server. For example, you can enable SSL termination for TCP upstream servers, restrict access with basic or JWT authentication, restrict access by geographical location, and set up dynamic deny-listing of IP addresses.

Both Apache and Nginx were built with security in mind, and are regularly updated to mitigate any potential security exploits. However, security is a shared responsibility, and at the end of the day, web servers, just like any other software, are as secure as the users who manage and customize them. Ensure that your administrators and developers are following security best practices while developing and deploying web applications.

OS support and interoperability

Apache and Nginx both support all Unix operating systems, including CentOS, Ubuntu, and Fedora. In terms of Microsoft Windows, Apache has full support, while Nginx currently only provides partial support. Although a work in progress, performance and scalability remain limited. For this reason, Nginx for Windows is still considered to be in beta.

If we talk about control panels, Apache works well with cPanel, OpenPanel, ZPanel, Ajenti, and more. Nginx also supports several control panels, including cPanel, Hestia CP, and Vesta.

Apache users can build applications using several languages, including Perl, Python, Lisp, Go, .Net, Ruby, R, and PHP. Nginx supports 7 languages: JavaScript (Node.js), Ruby, Java Servlet Containers, PHP, Perl, Python, and Go.

Both Apache and Nginx can run several content management systems (CMS), including WordPress, Magento, Drupal, and Joomla.

Ease of use

Getting started is quick and easy for both Apache and Nginx. You’ll typically have to run a small set of commands to get each server up and running. However, there are certain usability considerations:

• As we saw in the configuration section, Apache allows for granular configurations, whereas Nginx can only be configured via a central configuration file. So, if you require maximum configurability, Apache seems like the obvious choice.
• Both Nginx and Apache allow you to load modules. Apache’s module loading mechanism is dynamic, flexible, and easy to use, whereas loading modules on Nginx is a more rigid process. The open-source version of Nginx only supports statically loadable modules, which can only be added to the Nginx engine at compile time. The ability to load dynamic modules is available only in Nginx Plus, the paid version of the server software.

Documentation and support

Documentation and support are important factors when choosing an open-source web server.

Apache

Apache has extensive documentation regarding administration, security, fine-tuning, and integration with other applications, and thousands of third-party modules can be loaded natively. Moreover, you can get support from the developer community through the mailing list, Internet Relay Chat (IRC), and Stack Overflow. You can also consult the Apache Software Foundation’s comprehensive mailing archive at https://lists.apache.org.

The official bug report page allows you to report a bug, or raise a feature request. Even though some third parties provide commercial support for Apache (e.g., OpenLogic), none are officially endorsed by the Apache team.

Nginx

In the past, it was difficult to find extensive Nginx documentation in English, as most of the initial documentation was in Russian. Today, extensive documentation is available in both English and Russian, including beginner’s guides, administrator’s guides, and architecture references.

Nginx has separate mailing lists for Russian and English developers, along with an official page to report bugs. You can also join the official Nginx community on Slack to ask questions or interact with other developers. Unlike Apache, commercial support is also available for Nginx.

Static and dynamic content handling

Apache and Nginx handle static and dynamic content in different ways.

Apache

Apache’s robust MPM architecture equips it to process both static and dynamic content efficiently. It uses the traditional file-based approach to serve static content. To process dynamic content, Apache embeds language processors into the workers, which enables it to process dynamic content natively, without requiring any third-party component.

To enable dynamic processing, you can use the module of the relevant language, e.g., mod_perl for Perl or mod_python for Python.

Nginx

Nginx can serve static content just as well as Apache. However, it can’t process dynamic content natively. Instead, it off-loads the processing of dynamic content to external components (e.g. FastCGI, SCGI), and waits for their output before forwarding the response to the client.

The obvious disadvantage of this approach is that administrators will have to set up an additional service to interpret dynamic content. However, it can also offer a performance boost, especially if you deal with high levels of traffic. A standalone service is likely to process dynamic content much faster than a multi-functional server receiving thousands of requests per second.

Choosing between Apache and Nginx

We have seen that Apache and Nginx share many similarities. Both are open source. Both were built with security in mind, and both are regularly updated. It’s easy to get started with either, and both options offer extensive documentation and community support.

Both also contain features that may make you choose one over the other:

Apache can run on multiple platforms and operating systems, and integrates well with other software. It processes both static and dynamic content efficiently. Apache’s decentralized approach to configuration makes it the obvious choice for those requiring maximum configurability. Apache’s dynamically loadable module system makes it easy to customize and extend the server, while loading modules on Nginx is a more rigid process. In terms of Microsoft Windows, Apache has full support and Nginx only partial.

On the other hand, Nginx’s event-driven architecture is faster than Apache’s process-based architecture, especially during peak hours and longer runs. This means it doesn’t slow down as requests increase. Its centralized approach to configuration also contributes to better performance, as well as enhancing security.

Choose Apache if you:

• Want to implement decentralized configurations
• Prefer the process-per-request model and have abundant memory and CPU resources
• Don’t expect high levels of traffic
• Want to dynamically load modules
• Want built-in support for serving dynamic content
• Want a server that runs on Windows and Linux platforms

Choose Nginx if you:

• Want to serve tens of thousands of requests per second
• Prefer the asynchronous, non-blocking architecture that can work with limited resources
• Want to manage configurations centrally
• Are okay with loading modules statically
• Are okay with setting up a standalone service for dynamic content
• Want commercial support for your project

Using Apache and Nginx together

Nginx was originally developed to complement Apache. Even today, administrators often use Apache and Nginx together to get the best of both worlds: the performance of Nginx and the customizability of Apache.

One way to leverage the partnership is by deploying Nginx as a reverse proxy for an Apache web server. In such an architecture, Nginx performs all the resource-intensive tasks, including processing requests, serving static files, and caching. The application code runs inside a secure Apache server, which is only invoked when required (e.g. to serve dynamic content).

As Nginx can also be used as a load balancer, this partnership paves the way for horizontal scalability. You can seamlessly add more Apache servers to your architecture and configure Nginx to distribute traffic across the server pool.

Why is it important to monitor web server performance?

Regardless of whether you choose Apache or Nginx, it’s important to monitor the performance of your web server, as it helps you with the following:

• Ensuring high availability: Continuous server monitoring allows you to gauge system health and predict malfunctions.
• Detecting memory leaks: By monitoring metrics like memory usage, number of active threads, and garbage collection, you can find and fix memory leaks.
• Quickly resolving issues: Monitoring important metrics equips you with the context you need to quickly resolve issues.
• Achieving peak performance: Tweak configuration parameters and gauge their impact using performance metrics. Rinse and repeat until you achieve your ideal settings.
• Identifying bottlenecks: Analyze performance metrics for different components of your architecture, and identify potential bottlenecks.

Both Apache and Nginx offer built-in support for performance monitoring. Apache contains the mod_status module, which can be used to observe server activity and performance while Nginx includes the ngx_http_stub_status_module module, which lets you monitor active connections, total client requests, waiting connections, and more.

Conclusion

Both Apache and Nginx have their pros and cons. Despite Nginx’s modern design and unrivaled performance, Apache holds its own in the web server market, owing to its popularity, configurability, and compatibility. To choose the right one for your business, make sure that you carefully evaluate your specific requirements and objectives.