Every web application (website, electronic mailbox…) hides one or several web server(s). They satisfy the Internet users’ requests, by sending their browsers the files containing the requested page.
These files can be static and stored on the webserver (HTML, CSS); or they are dynamic and need an interpretation (such as PHP files). In this case the server will send a request to another service, which will provide it with a file it can analyze and send back.
There are many web server solutions: NGINX, Apache 2, Lighttpd, IIS (for Microsoft environments)… We will focus, in this article, on NGINX and Apache, two web servers that are operational on Linux environments, and used by NBS System.
Choosing a web server
A company usually has to choose a new technology to palliate an issue, or to set up a new tool. Thus, the first step is to precisely define the need the technology has to satisfy, as well as the constraints which it has to adapt to. That is the first sorting of the solutions: the company need to choose the ones satisfying the primal needs, and which adapts to the constraints.
This being done, one must choose between the short-listed technologies, in order to know which one fits the production context of the company. To do so, one has to study each stage of the technology’s life in order to find the most adequate solution for the company’s budget, its teams’ size and technical competencies, and its philosophy. There are two stages:
- The “build” stage: deployment and production launch of the solution.
- The “run” stage: maintenance methods and evolution, monitoring and metrology capacities of a solution.
The study of both these phases enables to quantify the set up and maintenance of each solution over time: these two visions are necessary to choose the one that best fits the company.
This way, NBS System chose two solutions: NGINX and Apache. They have the same goal, but accomodate different constraints, as we will see. The differences between these web server solutions are not very marked, but have the merit of being explained.
Ease of automation is an important criteria when choosing a technology, since it will impact the whole cycle of life of the server, from its creation to its desctruction, through its exploitation. It is all the more important for a managed hosting company such as NBS System, since web servers are our core business: their functionning has to follow our clients’ applicative changes. The automation of processes saves time, and avoids human mistakes.
Our team’s choice here is NGINX, which our experts find easier to mechanize than Apache. Its configuration format is, for them, more enjoyable and easy to manipulate than Apache’s one, which is a mix of XML and serialized language. Many specialized interpreters are available for NGINX‘s configuration, but we decided to code our own, to better answer our own needs.
Moreover, NGINX implements several functionnalities to ease automation: mechanisms that send information to centralized services (Syslog for instance), or modules with APIs allowing to control some aspects of NGINX’s internal functionning, such as caching. It avoids having to create these services oneself, and makes NGINX a tool that is particularly adapted to industrialization.
Web server and performance
The following considerations are based on the capacities and workingof NGINX solutions in version 1.2 and Apache in version 2.2 (both were stable when our technological choices were made).
Historically, NGINX is particularly renowned for its good results during performance tests. Apache, however, did not benefit from the same reputation, at least when we made our choice. It can be explained by several differences:
Weight of the processes
For every request sent to the server, a new process is launched, wether one is working with Apache or NGINX. The difference here lies within the weight of the processes (in the default configuration). Explanation: to serve dynamic pages, these two solutions use external services, such as the PHP interpreter.
For this, Apache uses internal modules (CGI, LDAP, PHP…). For each newly created process, these modules are dynamically charged. It wastes time, since the program has to check every time which modules have to be loaded, and it makes the processes particularly heavy. On NGINX, however, the equivalents of these modules or, by default, the CGI services are directly compiled in the solution’s configuration. NGINX’s processes are thus much lighter.
Let us imagine now that 90% of a website’s content is static, and 10% is dynamic. In the case of an Apache web server, 100% of the processes loaded the modules, which are however not used in 90% of the cases : the memory is blocked for nothing. With NGINX, the created processes have, by default, the capacity to provide static files. The server will mobilize the resources needed to interpret a dynamic page (external services) only in the 10% of cases when it is needed. These resources are thus saved 90% of the time.
That is how, from a certain number of visits on a website, the performance difference between the two solutions will be more and more tangible. To schematize, if you need 5 Gb of memory to serve a static page and 15 more Gb for a dynamic page, here is the quantity of necessary memory for each solution depending on the number of visitors:
|10 visitors||10x(5+15) = 200 Gb||9×5 + 1x(5+15) = 65 Gb|
|1 000 visitors||1 000x(5+15) = 20 000 Gb||900×5 + 100x(5+15) = 500 Gb|
Apache works with htaccess files, which is not the case of NGINX. They are “on the fly” configuration files, that a developer can include in his website. The use of these files has its advantages, but also has a negative impact on the performances. Indeed, for each received request, Apache will check all the files of the website looking for a htaccess file corresponding to its request, then read and interpret it. It takes time and slows the website down.
However, lately, new tests have been made to compare Apache and NGINX’s performances. If NGINX handles the processing of static files more quickly, no difference was no longer seen regarding dynamic files 1. Indeed, since its 2.4 version, one Apache process can handle several requests, which greatly improves the solution’s performances. Performance is thus no longer a determining factor in the choice of these solutions!
Web server and client autonomy
A managed hosting provider such as NBS System has a direct responsibility on its clients’ systems, and has “full powers” (root) on the machines. It is thus impossible to give the same level of control to their clients, or even to allow them to easily modify their configurations, in order to avoid conflicts, double interventions, etc.
Apache allows a delegation of the control over the machines to the clients, who are then more autonomous, via htaccess files. Indeed, a developer does not need to go through the hosting provider to include one of these configuration files on his website, and can modify them as he wishes. It avoids long exchanges between the two entities, and certainly saves time during the exploitation.
NGINX does not work with htaccess: all modifications must be written in the tool’s global configuration file. Only the hosting provider can do that, neither the developer nor the client have control over this file. It is however possible to grant modification rights to a client, through control consoles. It enables the client to have a certain level of autonomy on its website, all the while allowing the hosting provider to limit the range of this autonomy to modifications that do not threaten the working of the website.
The editor’s recommendations also have to be taken into account. Indeed, some of them do not work, for instance, without htaccess: it is the case of Magento or Prestashop. The latter generates “on the fly” htaccess files, which causes some issues with NGINX. Hybris does not provide any support if Apache is not used. Choosing NGINX in these conditions requires perseverance and technical knowledge.
Even if editors tend to remain within their comfort zone with Apache, this trend fades away: they provide more and more procedures adapted to the different types of servers.
Beyond all the pragmatic standards of choice, the feelings of the teams and the message conveyed by the choice of the solution also matter. For NBS System, it guided our choice toward NGINX: it is an open source solution, simple and efficient. Besides, there are developers of the solution in our team (they created the NAXSI module).
So, NGINX or Apache ?
As we said in the conclusion of our article on reverse proxy solutions, the more time passes, the less major differences there are between the solutions: they are more and more interchangeable, apart from some specific functionalities. Since the 2.4 version of Apache, this trend matches perfectly NGINX and Apache: when the performances are comparable, the choice criteria that remain are the preferences concerning automation and client autonomy, as well as the “emotional” proximity with the product.
We use NGINX for our own web services, as well as for some of our large clients who would rather have performance than autonomy. NGINX serves the static files, and there are PHP-FPM farms dealing with dynamic files. It is this horizontal scalability that brings them an optimal performance with little resource utilisation. For the majority of our clients however, we install Apache, in order to provide them this freedom and ease of work with the editors. The solutions answer here to the same need, but with different constraints!
1 Source : http://www.speedemy.com/apache-vs-nginx-2015/
Source: Denis Pompilio