Date published: April 21st, 2016
Posted in Server-Side, Site Performance | No Comments »
The Apache HTTP Server remains the most popular and widely-used web server today, but we are seeing an increasing level of Nginx deployments. Nginx (pronounced “engine X”) was released 11 years ago and has had a reputation as a lightweight but highly performant web server.
According to survey data published by Netcraft, Apache comprises 49.90% of HTTP servers with Nginx coming in at 2nd place with 16.03%. Usage growth of Nginx, however, has increased steadily since 2008 when usage was at approximately 2% resulting in an 8-year growth of about 14%. Despite Apache’s current overall strong-hold, its usage has actually dropped by about 10% over the past 15 years.
Plenty of developers and systems administrators might even say Nginx is superior to Apache. If that’s the case, why is Apache still the dominant http server? If Nginx is superior, why not use it instead of Apache?
Installation of Apache vs Nginx
Most Linux distros offer both Apache and Nginx as binary packages that can be very easily installed from the operating system’s official repository. FreeBSD users, however, will need to install Nginx from the ports tree rather than from pkg as with Apache. The source code of both Apache and Nginx are freely available if you need to install from source. So, there really is no difference between the two just comparing a basic installation of each involving just getting a basic HTTP server up and running.
Apache vs Nginx and mod_security
The mod_security module for Apache is a very powerful and popular tool used to analyze http requests and match them to a set of rules. If a match occurs, one has the option of doing something with that traffic; blocking it, allowing it to pass through, displaying a specific server error to the user, and so on. This makes mod_security an excellent and widely-used tool for securing websites against various attacks.
Installing mod_security for use with Apache is fairly simple; depending on your server setup, you may install it through WHM for cPanel servers, through custombuild for Directadmin servers, or by installing it from your Linux distribution’s repository. Apache’s main configuration file may need a slight modification to enable mod_security if the initial installation doesn’t modify it automatically. Once that’s done, mod_security is ready to use.
In contrast, mod_security for Nginx is fairly new and installation can be difficult. Mod_security for Nginx was introduced based on its popularity and due to so many depending on it for security. As overviewed in the previous paragraph, mod_security for Apache is installed by simply using the distribution package manager or server control panel. Mod_security for Nginx must be compiled into Nginx manually, using the mod_security source code, the Nginx source code, and a wrapper allowing mod_security to run as a standalone module alongside Nginx. In this case, you are also installing Nginx and mod_security from source rather than your distro’s package manager. This greatly complicates upgrading either, as they will have to be recompiled from source.
Alternatives to compiling Nginx and mod_security from source and using mod_security as a standalone are being developed but are likely a long ways from fully replacing the reliability and stability that Apache + mod_security currently offers.
For those who use Nginx, another option is to not even bother with mod_security and use other methods of securing the server instead. Fail2ban works well with Nginx but tends to be resource intensive when processing a high number of requests or log files. External 3rd-party WAFs (web application firewalls) such as Sucuri work fine with both Apache and Nginx. There are also WAFs specifically tailored to Nginx such as NAXSI that are installed on the server much like mod_security.
Apache’s .htaccess; what about Nginx?
Many web applications still depend upon .htaccess to function properly, with “workaround” tutorials for use with Nginx. Nginx does not use .htaccess or anything like it; all configuration is done in the main Nginx configuration file or each site’s configuration file in the sites-available directory. With Nginx, the http server must be restarted if a change is made as opposed to modifying settings in an Apache .htaccess file where no http restart is needed. This makes Apache an appropriate http server to use in shared hosting environments since a user may control http settings for their site with .htaccess without requiring root-level access to the server.
Those who are experienced and comfortable with using .htaccess to set redirects, manipulate mod_rewrite, block certain user-agents, and the myriad of other uses for .htaccess may find this to be a huge stumbling block for switching to Nginx. However, many of the features possible with Apache’s .htaccess file are also possible with Nginx; they just need to be set in a site’s sites-available file instead of .htaccess. We won’t use this post to go into specific how-tos but keep an eye on this blog and our knowledgebase for Nginx usage instructions.
Therefore, Apache vs Nginx from a .htaccess standpoint is really only a matter of requiring root-level access or not and writing settings with slightly different syntax in a different file. For those with a dedicated server or a cloud server / VPS, this issue relatively minor once you’re past that initial learning curve. It does, however, pose significant limitations for shared hosting environments and users without root-level access.
Apache and Nginx performance
At this point it may seem as though Apache is still superior to Nginx; however, Nginx has some significant performance advantages over Apache that make it a worthy contender. Apache is a threaded process-based http server while Nginx is event-based and very scalable. When websites were small in size and optimized for dial-up or early broadband connections, Apache performed fine while serving many requests. Websites were not optimized for an interactive user experience; they were optimized for browser and connection limitations. Those limitations only exist in sparse numbers today and most users are able to download large files very quickly and enjoy cutting-edge features that didn’t even exist 10 years ago.
Due to its design, Nginx outperforms Apache when handling static media. This makes Nginx a very popular choice as an http server for Python applications such as Flask and Django. Apache with mod_wsgi works well for small sites with light traffic but performance problems tend to occur as a site grows. Python web applications require that static media be served separately so it’s important that the methods to do so are efficient. Some developers will use both Apache and Nginx; Apache handles serving the application and Nginx handles serving the static media.
That advantage isn’t just limited to Python applications – any application will benefit greatly from an http server that handles media and requests in a modern, efficient manner. Nginx can handle many simultaneous requests, sending to the background any request that isn’t actively doing something. Apache, on the other hand, handles connections in a queue making the server vulnerable to running out of memory at worst or heavily bogged down at best under a high traffic load. While there are a number of tweaks and fixes to help Apache avoid crashing, it’s very difficult to scale without time-consuming manual intervention.
So, despite the drawbacks of Nginx the performance advantages are quite valuable. If you’re running a web server, the goal is to serve your websites efficiently and quickly to your visitors so they aren’t met with an error or slow-loading page. Choosing an HTTP server is not a task to take lightly, however, as that decision is not easily reversed later. Unless you run a very small site you will be stuck with whichever one you choose – Apache or Nginx – without significant time spent reconfiguring the server.