Apache vs Nginx: Which Is Better?

Web Servers are computers that are dedicated to running a specific type of server software. The most common type of software found within these servers will typically be Apache and NGINX. With most hosting providers, this is predetermined by the hosting provider itself, although there are surely options out there that will manually allow you to pick which one you prefer. That being the case, the use case behind this software is to process the incoming requests in order to access them.

The software itself is designed to perform tasks, and handle a massive number of requests in a small time frame. Now, the important part to note here is that this software also needs to work with specific other components, so it needs to adapt. To give you a bit more of a perspective, you will need a server with HTTPS support such as Apache or NGINX, PHP, which is the language through which many Content Management systems run in such as WordPress, and the database software behind this, which will most likely be MySQL.

Now, the main reason why Apache, as well as Nginx, might be so familiar to you is due to the fact that, together, both of them power over 50% of the traffic you see online, and both of them can even handle diverse workloads and work alongside other software with ease.

However, these are seen more as buzzwords, and not a lot of people actually know what they are, what they do, and how they work in the background.

Before we get into them, let’s see what they actually are.

Apache: A Brief History

Apache can be seen as this HTTP server software currently under development under the Apache Software Foundation, which began work on it in 1999. It was originally created by Robert McCool in 1995, and it is one of the most popular options typically found on many hosting providers out there. This is due to the fact that it has vast documentation, alongside integrated support from other software projects.

The main reason why most network administrators tend to pick it is due to the fact that it offers a high level of flexibility, and it has a module system that is dynamically loadable and can process a large number of integrated languages. All of this is made possible without the need for external software, which is quite unique.

One of the best aspects and reasons as to why you might want to pick this over NGINX is due to the fact that it is maintained by an open community of developers under ASF, and it runs on Linux, making it one of the key components in the LAMP stack. The LAMP stack consists of Linux, Apache, MySQL, and PHP.

NGINX: A Brief History

NGINX was created by Igor Sysoev. It has an interesting backstory in the way that it was created as this answer to a problem known as C10K, which was a challenge in which web servers needed to handle tens of thousands of concurrent connections as a requirement for the modern web infrastructure.

Development started in 2002 and the initial release came to market in 2004, making it much newer than Apache, but as you learn a bit more about it, you might notice why this is also somewhat of a downside.

That being said, the progress was achieved through an asynchronous, event-driven architecture, and as such, it has managed to grow quite a lot in popularity due to the fact that it had a low impact on resources, as well as an ability to scale easily. It actually specializes in serving static content quickly and is designed to pass dynamic requests off to other software that is better suited for handling such a workload.

Now, the main reason why you might see that administrators have picked NGINX over Apache is due to the fact that it is efficient, has a higher level of responsiveness and traffic support. The unique aspect of NGINX however is in the fact that it can work as a reverse proxy as well as a load balancer. This allows it to fill a lot more roles than Apache.

Differences between Apache and NGINX

There are a lot of differences between these two, however, for the purposes of giving you a better perspective of how all of it works, we’ll discuss the three main aspects you need to worry about, and these include server management, server configuration, and modules.

Request Management

When it comes to request management, Apache takes advantage of multi-processing modules or MPMs in order to handle the connections, and you can choose from a total of three MPMs.

First, you have the mpm-prefork, which is this module that can create a single-threaded process to handle each request. Each of these processes can handle a single connection.

Then you have the pmp-worker that is this module that can launch a multi-threaded process, with the exact thread that is capable of managing a single connection.

Finally, you have mpm_event, and this is a module that works similarly to the mpm_worker except that it is optimized to keep the connections alive.

Now, apache enables you to choose which module you want to use, and you can swap these on a per-need basis.

Let’s compare this to how NGINX works. It can manage a lot more requests by using fewer resources and this is what makes it a lot more efficient. To do this, however, it uses an event-driven approach and this means that it uses a multi-threaded process, where each thread can handle multiple connections.

Server Configuration

Discussing the server configuration, Apache uses .htaccess files to set specific rules. These rules then become a fundamental part of how everything works in terms of handling incoming requests, and these files include everything from redirection rules to memory limits.

The beauty of Apache here is in the fact that it allows you to individually set up .htaccess files, and this is the case for every directory on the server tree. This means that every .htaccess file you run into a request path needs to be interpreted separately, and they can take a bit longer to execute as a result.

When we see the other end of this spectrum, NGINX doesn’t really provide you with this level of flexibility, and you have a single file that has the responsibility of governing the entire process, which makes it quicker, although do you lose in terms of flexibility.

Modules

This is where Apache shines.

In NGINX, you cannot really disable modules once they are compiled, as they have to be compiled into the NGINX core in order for you to use them.

However, when it comes to Apache, you have modules that act like add-ons that you can use alongside your server software in order to extend its functionality. Since it’s a bit older, Apache has a larger selection of these modules, and even allows you to install them, enable them, and disable them as per your specific need.

Static and Dynamic Content

When it comes to the real-world use-case scenarios in terms of Apache and NGINX, you’re ideally looking at the way through which each server handles the requests for static as well as dynamic content.

Apache servers can handle static content through the usage of more conventional file-based methods. The performance of these operations is the function of the MPM method.

Now, apache can also process dynamic content by embedding a processor of the language you are using into each and every one of your specific instances, and this is what allows it to execute dynamic content within the webserver without the need to rely on external components altogether.

Apache shines in the fact that it can handle dynamic content internally, and this means that the configuration can be simpler as a result. The communication does not need to be coordinated with any other software, and modules can be swapped if at any point in time your specific needs change.

Discussing NGINX, it doesn’t really have the ability to process dynamic content, at least not natively. In fact, in order to process and handle PHP as well as other requests for dynamic content, NGINX has to pass to an external processor for its execution and wait for the rendered content to be sent back. This in turn results in a bit of a longer period for processing.

In fact, the communication has to be first configured between NGINX as well as the processor over one of the protocols NGINX can speak to, including http, FastCGI, SCGI, wUSGI, and memcache.

As you might have noticed by now, this can complicate things a bit, and if you are trying to anticipate the number of connections, an additional connection has to be used for each call to the processor itself.

Distributed vs Centralized Configurations

If you’re an administrator, or just want to become one, and that is the main reason you are reading this article, you have to know that one of the most important differences between the two pieces of the software discussed here is if the directory-level configuration is permitted within the content directories themselves.

You see, apache includes this option to allow additional configuration on a per-directory basis through the inspection as well as the interpretation directives in hidden files within the content directories themselves. These files, as previously discussed, are the .htaccess files.

These files reside within the content directories themselves, and when they handle a request, Apache has to check each component along the path to the requested file for a .htaccess file that applies the directives which are found within it.

This allows for the decentralized configuration of the web server itself, and this is often used for the implementation of URL rewrites, access restrictions, authorization, and even authentication alongside other caching policies.

On the other end of the spectrum, you have NGINX, which doesn’t actually interpret .htaccess files.

It doesn’t even provide a mechanism for evaluating any per-directory configuration, outside of its main configuration file.

As such, it’s a lot less flexible than the Apache model, but this does provide it with certain advantages not found on Apache.

You see, .htaccess can lead to increased performance. This is due to the fact that the most basic Apache setup allows .htaccess In any directory, allows the server to check for each of the files in the parent directories that lead up to the requested file. If one or more .htaccess files are found during the search, they can be read and interpreted.

Now, through not allowing directory overrides, NGINX can serve requests faster by doing a single directory lookup and file read for each request.

Now, another advantage you get is a security-related advantage, where distributing directory-level configuration access also distributes the responsibility of security to individual users, who might not be trusted to handle this task for example.

An In-Depth Look at Modules

As previously mentioned, both NGINX, as well as Apache, is extensible through module systems, however, they do work a bit differently when it comes to their use-cases as well as implementation.

As previously mentioned, Apache has this module system that allows you to dynamically load and unload any modules that you need in a specifically given time frame, now, the apache core is always present, and the modules can be turned on or off while adding or removing any additional functionality.

Due to this Apache can use this functionality for a large variety of tasks, and due to the maturity of the platform, there is an extensive library of modules available.

NGINX implements another module system, and it is different in several ways. You see, on the NGINX spectrum of things, the modules are not dynamically loadable, and they have to be selected as well as compiled into the core software.

For most of the users, this will make NGINX a lot less flexible. They are useful in the way that they allow you to dictate exactly what you want out of your server by only including the functionality that you will actually need. They can also allow many of the capabilities that the Apache modules have, such as compression, rate limiting, logging, rewriting, geolocation, authentication, encryption, and much more.

File vs URI-Based Interpretation

In other words, this is an analysis of how the web server can interpret requests as well as map them onto the resources on the system.

Discussing Apache in this regard provides this ability to interpret a request as a physical resource on the filesystem, however, it can be a URI location that could require abstract evaluation.

Apache uses <Directory> or <File> blocks, and it utilizes <Location> blocks for abstract resources.

Apache was designed as a web server, so the default method of interpreting requests is as filesystem resources. It tracks the document root and appends the position of the requests which follows the host and the port number to try and find the file in question.

When it comes to NGINX, it was originally developed to work both as a web server as well as a proxy server. It works with URIs, and it translates to the filesystem when required. This means that NGINX configuration files are constructed as well as interpreted, and it does not provide a mechanism for specifying the configuration for a filesystem directory and parses the URI itself.

Support

Due to the fact that Apache has been around for quite a long period of time, the server has amazing support. There’s this enormous library of first and third-party documentation which is available for the core server, and this streamlines things a lot for new administrators as a result.

It’s important to note that Apache also gets much more support from third parties as well, due to the fact that it has a larger market share and it has been available for a prolonged period of time. People are comfortable with it, understand it, and support it.

NGINX has an increased level of support, however, it only grows as much as its implementation grows. In other words, the more people that end up using it, the higher level of support it will actually have.

Throughout its history, it was difficult to find documentation in English due to the fact that it was originally developed in Russia, so the instructions were in Russian, however as it grew, the documentation was filled out, and there are many resources available online nowadays.

Level of Security in Each Option

Apache keeps websites safe and even offers DDoS attack handling alongside what is known as the mod_evasive module, and this module responds to HTTP, DoS, DDoS, and brute force attacks.

On the other end of the spectrum, you have NGINX, which has a significantly smaller codebase in comparison. However, this is not always a downside, as there’s less code to be compromised. It also has a list of security advisories and can protect your website well.

Speed Test: Apache vs NGINX

To test things out, I set up two separate servers, one running Apache, and one running NGINX

First, let’s see how Apache performed.

The page I tested was a simple “Hello World” page. To do this, I entered this code:

<HTML>
<head>
<title>PHP Test</title>
</head>
<body>
<?php echo '<p>Hello World</p>'; ?>
</body>
</html>

Here’s what it visually looks like:

• PageSpeed Insights – Google Developers

Mobile:

Desktop:

• GTmetrix | Website Performance Testing and Monitoring

• Pingdom Tools: Website Speed Test

And now, let’s see how NGINX performed.

And here are the search results from three testing platforms.

• PageSpeed Insights – Google Developers

Mobile:

Desktop:

• GTmetrix | Website Performance Testing and Monitoring

• Pingdom Tools: Website Speed Test

As you can clearly see, I’ve had nothing but exceptional results on both, with minimal differences.

Apache and NGINX Combined Together

Through the analysis of what they are, and how both of them work, the chances are high that you have a better perspective of how each one of them works. Now, you might be thinking to yourself, how do I take advantage of both of them?

When we look at how most other users combine them, you’ll find that NGINX is used in front of Apache as this reverse proxy, as this allows NGINX to handle all of the requests from the clients, and as such, this takes advantage of its fast processing speed as well as ability to handle a lot of connections concurrently.

Now, NGINX specializes in static content, as the files are served quickly as well as directly. For dynamic content, it can proxy the request to Apache, which processes the results and returns the rendered page.

This setup will work exceptionally well due to the fact that it allows NGINX to function for sorting, as it can handle all of the requests and pass on the ones that it cannot to Apache.

You can even add additional backend servers if required with this setup.

By combining them, you’re essentially getting the best of both worlds. The only problem that could arise is when they both listen to the same ports, so when you give them different ports to listen to, your system functionality will be at an optimal level.

Summary

Both Apache as well as NGINX fill a specific role in the market and serve to tailor towards a different audience.

Why Choose Apache Over NGINX

• When you need access to the .htaccess files due to the fact that you can override system-wide settings on a per-directory basis through them, which can provide optimal performance to your server.
• When you have functional limitations due to the fact that the modules open up a lot of possibilities for you that you will simply not find in NGINX.

Why Choose NGINX Over Apache

• When you’re loading fast static content due to the fact that it can handle static files from a specific directory a lot quicker than Apache.
• When you have a high-traffic website, as it can provide the content to a lot of people without losing out on speed. The upstream server processes never get blocked due to the fact that NGINX can process multiple static content requests concurrently.

If you want to pick which one works better for you, well, it will highly depend on your specific use-cases and requirements. Most of the time, the hosting service you choose will have this predetermined for you, so make sure to watch out before deciding to go with one.

Pick the one that is perfect for your specific needs, as you will likely end up with it for many, many years.

Related Articles

• How to Configure Nginx and Apache on the same Ubuntu VPS or Dedicated Server
• Want info about best web hosting? Clicking this link can be of great help.