Nginx vs Apache

Let’s put these two into a little bit of context first, by talking about their historical backgrounds.

Apache

Apache emerged first in 1995, developed by Robert McCool (real name).

Before that was Tim Berners-Lee’s NCSA HTTPd and CERN HTTPd web servers – CERN is now defunct. However, the Apache HTTP Server was set to dominate the market and has been the world’s favourite since 1996.

Three years later, the Apache Software Foundation company took over Apache.

Today it is an open-source, cross-platform web server that still maintains its position as the most popular on the planet.

It’s well known for its power, broad support, and flexibility. Used by high-profile companies that include IBM, Cisco, General Electric, Facebook, LinkedIn, eBay, Salesforce, and many more.

Nginx

While not among the oldest web servers around, Nginx gained a quick advantage since its launch in 2004. Which is  due to offering better performance for high traffic and static websites.

Some modern web hosts now prefer it to Apache. While others use an enhanced version of Apache, like A2 hosting, to maintain high speeds.

Work on Nginx next began in 2002 by Russian developer Igor Sysoev to solve the C10K issue. Wherein – during the modern internet’s development – web servers struggled to manage ten thousand simultaneous connections.

The IPO went live in 2004, bringing to market high scalability on low resources hardware. As well as the special ability to process static media swiftly. Which allowed them to delegate dynamic requests to software that is better equipped to do so.

Worth £670 million in 2019, it is well-known for lightweight efficiency and responsive handling of load – a core web server, with noteworthy proxy features.

The biggest difference between Nginx and Apache. You will learn in Nginx vs Apache clash that they use different underlying architectures to handle requests (traffic/connections).

Apache Handling

Apache does its request processing via Multi-Processing-Modules (MPMs).

The modules are mpm_prefork, mpm_worker, and mpm_event.

Prefork is Apache’s oldest MPM – there from its inception – and is somewhat responsible for Apache developing a bad performance reputation. When using this mode, Apache handles each request by spawning processes with a single thread.

Prefork was efficient: working with mod_PHP, it led to Apache server giving each individual process a PHP interpreter embed, regardless of if it had to handle CSS images or files.

Worker and Event Modules

Worker and event modules came, later on, tackling these weaknesses by using PHP-fhm. Process spawning in both can deal with multiple threads, with each thread handling a single connection. Because threads work more efficiently than processes, these MPM’s can be scaled better than the prefork MPM.

Because this is because of the greater number of threads versus processes, new requests instantly have a free thread available rather than waiting for a free process.

The event module differs slightly to worker as it’s streamlined for dealing with keep-alive collections. Connections hold threads whether or not request is being actively made, holding on for as long as that connection is alive.

Note that the worker module manages the delegation of connections. Which will be keep-alive so that the module isn’t overwhelmed by such requests.

Nginx Handling

Nginx had the advantage of emerging later than Apache.

It allowed them to be aware of infrastructure issues.

Which could arise alongside connection concurrencies when scaling a website.

They designed their architecture from the ground up as a non-blocking, asynchronous, event-driven request managing algorithm.

We described earlier how Apache uses processes for every connection, with the worker MPM able to delegate this by thread subset (like opening up several tabs in a single browser).

You might see a problem here: with modern websites requiring hundreds of requests per page load; the more the traffic, the more expense – ie., a multicore, multithreaded CPU can perform better but also costs more and takes time to work.

The Clash

Apache’s event MPM closed this gap further but some studies suggest that it cannot outperform Nginx (almost certainly not with static files).

With Nginx, each worker process can handle thousands of incoming connections (hundreds of thousands in fact) per worker. So while they typically have one worker process for each core CPU, it’s not necessary to delegate connections to threads / extra processes.

Nginx achieved this via a fast looping mechanism that continually searches for and handles events. Which separates actual work from overall collections. Workers only come into play when a new event is detected.

Let’s talk about distributed versus centralised configurations. Administrators will want to know the differences here – ie., can you do directory level configuration inside content directories?

Apache .htaccess 🐃

For its configuration, Apache uses .htaccess. These are options to additionally modify individual content directories inside hidden files stored on those directories (we call these files .htaccess files).

This gives the administrator lots of flexibility with modifying how Apache manages incoming requests. For instance: maximum upload file sizes, memory limits, URL rewrites, redirection rules, encoding headers, cookies, and more.

There’s no need to grant access to the full configuration file for web content, allowing permitted web software to easily configure the environment without that central access.

Two examples: content management systems, and top hosting resellers with control over the main configuration while giving their customers permissions for specific directories.

Nginx .htaccess 🤖

Nginx does not have this interpretation ability for .htaccess files, nor the ability to configure per-directory without access to the central configuration file. While it’s less flexible upfront, there are certain benefits.

Indeed, this reduced flexibility leads to increased performance. In other words, permitting .htaccess access winds your performance.

The typical reason: each connection request will lead to the server checking for the requested files for every parent directory (because .htaccess can often be in any directory) until that requested file is found. In the event that more than one .htaccess file is discovered while searching, each must be read and interpreted.

Because Nginx doesn’t allow directory overrides, requests can be handled quicker because the search involves only one directory / one file-reading per request (if that file is located inside the typical directory schema).

You will often hear talk of Apache vs Nginx in terms of managing requests for dynamic and static content.

In short, static content doesn’t (or rarely) changes, staying the same on your website. For example site pages/videos that stay the same no matter how many times they’re seen.

Dynamic content, on the other hand, constantly updates according to trends, user input, and accessible information – e.g. RSS / social media feeds, email newsletters, and restricted/personalized content.

Apache 🤖

Apache caches its static content so that it’s pre-prepared before your visit. Dynamic content is processed inside the webserver without relying on external components. With this built-in handling, configuring dynamic processing is simple. No add-on software is needed.

Nginx 🐃

Nginx cannot internally process dynamic content. For instance, PHP requests for the like require Nginx to swap out to an external processor – it can only send the rendering back once completed. The configuration of that communication chain is more complicated. But it excels in static content, able to efficiently deliver this simply.