TL; DR: We assess two of the most popular web servers: NGINX and Apache, on six key points of comparison (performance for static vs. dynamic content, OS support, security, flexibility, documentation, and support). We’ll find that the two are worthy competitors, but Apache‘s .htaccess file makes it particularly appealing to shared hosting customers. Meanwhile, NGINX reigns supreme for dynamic content support, and due in part to its more advanced feature offerings, is most popularly used by VPS and dedicated hosting users. Finally, we’ll go over our recommendations for hosting your next web app project.
There was a time (~late 90s-2011) when the Apache web server served around 60 percent — and at times even more — of the world’s websites. That percentage has since fallen below 35 and is still dropping at quite a significant rate. Meanwhile, Microsoft’s IIS web server has held a somewhat steady, slightly increasing, share of the market, reaching 30 percent today. Third place is held by a competitor called NGINX (pronounced “engine-x”), which currently serves around 16 percent of all sites, and that rate is steadily growing by about one percent each year.
I’ll note that some web surveyors place the market shares of Apache and NGINX much higher, considering IIS a lesser competitor. Reality likely resides somewhere in the middle, but the overall trends are clear. Considering only the busiest sites on the Web, Apache holds about 46 percent of the market share, but that portion drops by about four percent annually; NGINX holds a strong second place with 24 percent of the market share and is growing at a rate of about three percent each year. Clearly NGINX is enticing the world’s biggest web properties with something!
In this article, we’ll make NGINX/Apache comparisons for the following areas of interest:
First, let’s make sure we’re all familiar with the web servers we’re comparing… Or you can skip to our summary review of Apache and NGINX, which includes our hosting recommendations.
Apache Overview
Apache is the web server component of the popular LAMP (Linux, Apache, MySQL, PHP) stack. Though there are many other web stack components these days (e.g., NodeJS, rich clients JS frameworks, various cloud services, etc.), LAMP still remains very popular.
The Apache web server has a rich set of features that can be enabled through installing one of the approximately 60 official modules or one of the many other unofficial modules that also exist.
Over the years, Apache has developed several methods for processing web requests to improve its efficiency (mainly RAM usage and latency). In a world where ever more concurrent web requests needed to be handled by sites, and where the served page sizes got a lot bigger, these newer methodologies were necessary.
The Apache request processing methodology can be configured in one of three ways. I’ll break down the three main Multi-Processing Modules (MPMs) below:
- process model: This is the original “pre-fork” method; it does not scale well with many concurrent connections, as it consumes a lot of RAM and might even refuse connections at high loads. Smaller sites won’t notice this, but larger sites likely will.
- worker model: This creates a single control process that is responsible for launching child processes. Each child process then creates a fixed number of threads, as well as a listener thread. The listener thread listens for connections and passes them to a thread for processing when they arrive. Though this model scales much better than the pre-fork method, it can still run into scaling issues for very high-traffic sites, due to the single control process bottleneck.
- event model: This is similar to the worker model, but it creates one listener thread which listens for connections and passes them to a worker thread for processing. This MPM handles long-running connections much more efficiently on a single thread (KeepAlive handling). Since Apache 2.4, the event model has been deemed stable and is now also the default setting if the operating system can support it.
You can also try compile-time and run-time options for improving Apache performance.
NGINX Overview
NGINX was created in response to the C10K challenge of handling at least 10,000 simultaneous client connections on a single server. NGINX uses an asynchronous, event-driven architecture to handle these massive amounts of connections. This architecture makes handling high and fluctuating loads much more predictable in terms of RAM usage, CPU usage, and latency.
The main difference between NGINX and Apache, in terms of the event models, is that NGINX does not set up extra worker processes per connection. In most cases, the recommended NGINX configuration is running one worker process per CPU, maximizing the hardware’s efficiency.
NGINX also has a rich set of features and can perform various server roles:
- A reverse proxy server for the HTTP, HTTPS, SMTP, POP3, and IMAP protocol
- A load balancer and an HTTP cache
- A frontend proxy for Apache and other web servers, combining the flexibility of Apache with the good static content performance of NGINX
NGINX supports FastCGI and SCGI handlers for serving dynamic content scripts such as PHP and Python. It uses the LEMP stack: a variation of LAMP using the phonetic spelling of NGINX (Linux, “En-juhn-ex,” MySQL, PHP).
NGINX vs Apache: Performance, Support, Security, & Docs Compared
Now let’s compare both web servers in several fields. We’ll find that Apache and NGINX are worthy competitors, but depending on your use case, one may be better suited for your project than the other. Don’t worry, I’ll sum it up nicely in my concluding NGINX/Apache comparison.
Performance
Below we’ll contrast the performance of Apache (using the event MPM) with that of NGINX in both static and dynamic content serving roles.
Static Content
NGINX is about 2.5 times faster than Apache based on the results of a benchmark test
running up to 1,000 concurrent connections. Another benchmark running with 512 concurrent connections, showed that NGINX is about two times faster and consumed a bit less memory (4%).
Clearly, NGINX serves static content much faster than Apache. If you need to serve a lot of static content at high concurrency levels, NGINX can be a real help.
Dynamic Content
A 2015 benchmark comparing dynamic content serving by Apache and NGINX found that the Apache event MPM, when paired with the PHP-FPM module, can handle about the same concurrency as can NGINX with PHP. Another web server performance comparison showed similar results. The reason for this is almost all of the request processing time is spent in the PHP runtime environment rather than the core part of the web server. The PHP runtime environment is pretty similar between both web servers.
In terms of PHP (and likely other languages as well), the dynamic page server performance is practically equal with a proper Apache module setup (PHP-FPM + FastCGI). If you really want to speed up dynamic pages, you have several options: add a Varnish or Memcached caching layer, switch to a faster PHP runtime (e.g., HHVM), do load balancing, or add more hardware.
Unfortunately, the superior static page serving performance of NGINX does not translate to the serving of dynamic pages. Both web servers score about the same on this point.
Operating System Support
Apache runs on all kinds of Unix-like systems (e.g., Linux or BSD) and has full support for Microsoft Windows. NGINX also runs on several modern Unix-like systems and has some support for Windows, but its Windows performance is not as strong as that of other platforms.
Apache comes out somewhat stronger here.
Security
Both projects have an excellent security track record for their C-based code base. The NGINX code base, however, is significantly smaller by several orders of magnitude, so that is definitely a big plus from a forward-thinking security perspective.
There is vulnerability reporting available for Apache 2.2 and 2.4. NGINX also has a list of recent security advisories. Apache offers configuration tips for DDoS attack handling, as well as the mod_evasive module for responding to HTTP DoS, DDoS, or brute force attacks. You can also find helpful resources for dealing with DDoS threats on the NGINX blog.
Flexibility
Customizations to the web server can be done through writing modules. Apache has had dynamic module loading for the longest time, so all Apache modules support this.
This is, however, not the case for NGINX. In the beginning of 2016, NGINX got support for dynamic module loading; previously, NGINX required the admin to compile the modules into the NGINX binary. Most modules do not yet support dynamic loading, but over time they probably will.
Apache clearly leads on this point.
Dynamic Module Loading & Modules
Both Apache and NGINX have a large and growing set of specific feature modules.
Apache Modules:
- Official Modules (Found in the Modules section of the Apache documentation)
- Module List on Wikipedia
Unfortunately, a well-maintained list of all third-party modules does not seem to exist yet.
NGINX modules:
- Official Modules (found in the Modules Reference section of the NGINX documentation)
- Third-Party Modules
It’s not easy to say if Apache or NGINX has a clear advantage here, but most of the core needed module functionality (e.g., proxy-ing, caching, load-balancing, etc.) is available for both web servers. NGINX looks stronger in the area of acting as a reverse proxy for TCP and email (SMTP, IMAP, POP3) connections. In the area of media streaming modules, the commercial NGINX Plus version also looks stronger.
Apache .htaccess
NGINX does not support something like the Apache’s .htaccess file.
Using .htaccess files, one can override system-wide settings on a per directory basis; however, for optimal performance, these .htaccess directives should be included in the main configuration file(s) whenever possible. This is not possible in the case of shared hosting environments, but it can add a lot of flexibility for shared hosting users.
Documentation
The documentation for both Apache and NGINX are excellent, including the NGINX wiki. NGINX also offers online and on-location training sessions on a variety of NGINX topics — including exam certifications.
Support
Apache community support is done through mailing lists, IRC, and Stack Overflow. Commercial Apache support is available from a number of third-party companies, such as OpenLogic, but no official list is maintained by the Apache Foundation.
NGINX has community support through mailing lists, IRC, Stack Overflow, and a forum. The company behind NGINX offers a commercial product called NGINX Plus, which has support for a set of extra features regarding load-balancing, media streaming, and monitoring.
Apache vs NGINX in Review
Both web servers, in their latest versions, can compete with each other in most areas. For static content NGINX is king, but for dynamic content the performance difference is quite slim. NGINX does shine with some of its more advanced features (media streaming, reverse proxying for non-HTTP protocols), as well as its commercial support and training.
Shared hosting users might prefer the convenience of the Apache .htaccess file, and Apache better supports loading various dynamic modules, a feature that NGINX only recently added. NGINX is mainly used for VPS hosting, dedicated hosting, or cluster containers.
High-traffic website ownerss that need to serve a lot of static content and/or media streams will probably prefer NGINX (or use a combination of Apache and NGINX). In most other website use cases, either web server will do the job just fine. To get started with either web server, you’ll need a solid Linux hosting provider. Luckily, our team compared the best providers and can point you in the right direction for Linux hosting for shared or virtual servers.
Well, there you have it. If you still have questions before you select NGINX or Apache for your next web project, be sure to let us know below!
HostingAdvice.com is a free online resource that offers valuable content and comparison services to users. To keep this resource 100% free, we receive compensation from many of the offers listed on the site. Along with key review factors, this compensation may impact how and where products appear across the site (including, for example, the order in which they appear). HostingAdvice.com does not include the entire universe of available offers. Editorial opinions expressed on the site are strictly our own and are not provided, endorsed, or approved by advertisers.
Our site is committed to publishing independent, accurate content guided by strict editorial guidelines. Before articles and reviews are published on our site, they undergo a thorough review process performed by a team of independent editors and subject-matter experts to ensure the content’s accuracy, timeliness, and impartiality. Our editorial team is separate and independent of our site’s advertisers, and the opinions they express on our site are their own. To read more about our team members and their editorial backgrounds, please visit our site’s About page.