Stress test Apache and Nginx on EC2 MicroInstance

A few years ago, when I was introduced to Amazon EC2, MicroInstance was launched with Ubuntu 10.04 LTS on board. It raised Apache and configured several virtual hosts, including a MODx Revolution blog. A free minute fell here and I wondered what would happen if a crowd of readers suddenly came upon my hidden blazhik. In general, there is nowhere to run from to her, but the spirit of knowledge, instilled in her childhood by multiple views of the newsreel "I Want to Know Everything", was haunting. I have not yet been able to participate in highly loaded projects, so a little research of the materials on the network was carried out. From the blog to the blog the statement roams that it is necessary to refuse use of Apache in favor of Nginx. This statement seemed strange to me, given the history of the Apache project and the community of developers around it. Can't the Apache developers solve the problem of prefork swearing everywhere? Is this really so I decided to find out. Read about the results under the cut.

Training

Having studied the topic in more detail, it turned out that in addition to MPM (Multi-Processing Module) prefork, Apache also has mpm-worker and mpm-event modules, which process requests from several users in one program stream. The mpm-event and mpm-prefork modules communicate with php via fastcgi. Compare their work with nginx and it was decided.

First of all, I decided to see how Apache behaves in prefork mode with a large number of requests. The siege utility with 40 threads was launched. Apache created many processes and the logs were filled with messages about memory overflow. After that, the server became unavailable and had to do terminate for this instance, since it did not succeed in waiting for a reaction for 5 minutes on reboot. A new instance was created, to which the old ebs was connected. As a result, it was experimentally established that the following settings are optimal on the EC2 MicroInstance with its memory capacity of 630MB:

    StartServers          3
    MinSpareServers       3
    MaxSpareServers       7
    MaxClients           27
    MaxRequestsPerChild   3000

Now it was possible to load the server without fear of losing its control.

It was decided to test the following configurations:

• apache mpm-prefork with mod_php
• apache mpm-prefork with mod_php + nginx reverse proxy
• nginx with php-fpm
• apache mpm-worker with php-fpm
• apache mpm-event with php-fpm

During testing, the thought came that nothing prevents apache in mpm-prefork mode from working with php-fpm and this configuration was also added to the tests.

I will not talk about how to install the configurations used in this article; you can easily find this information on the Internet. I note only that in many howto the same error is duplicated for bundling mpm-worker or mpm-event with php, namely: in the commands of the package manager it is specified to install the php5 package, in fact, you need to install the php5-cgi package.

First of all, I was interested in how many requests a web server can withstand. Therefore, I decided to use the siege utility for testing. Having experimented with JMeter, I came to the conclusion that it is more suitable for determining the reaction time to certain events. Thus, the main parameter of interest to me from the output of the siege utility was Availablility. Based on this, the parameters of the siege utility were selected so that Availability was less than 100%, but not too small. All tests used the number of threads 20 (-c) the number of repetitions 20 (-r) benchmark (-b) mode.

To process the test results, an Excel file was created, in the tables of which the results displayed by the siege utility were entered. According to the results of five tests, the arithmetic mean and standard error of the arithmetic mean are found. A Availability diagram is built for different configurations.

A simple script was written that performs the required number of tests and processes the results of siege output for copy paste in Excel:

#!/bin/bash
n=1
touch tmp.out
while [ $n -le $2 ]
do
        siege -b -q -c 20 -r 20 -i -f $1 >> tmp.out 2>&1
        sleep 60
        n=$(( n+1 ))
done
cat tmp.out | sed -nE '/Transactions/,/Shortest/p' | awk -F":" '{print $2}' | awk -F" " '{print $1}'| sed 's/\./,/g' | xargs -L12 | sed 's/ /;/g'
rm tmp.out

The script parameters are the URL file that was generated from the sitemap, and the number of iterations in the case of these tests was always 5. sleep 60 is necessary to complete all the queues from the previous iteration.

In the process, it was decided to attach CloudFlare to the CDN website, and at the same time see how this service affects the load capacity of the web server. To do this, a subdomain with a direct site address was added to DNS CloudFlare and an alias was added in the virtual host settings. Another URL file was created for direct access to the site.

results

You can see detailed test results in this file . Here I give only diagrams.



It is not clear why it stands out from the general trend of apache mpm-prefork through CloudFlare.

Since the results obtained had large errors due to the significant spread in the values ​​of each pass, it was decided to conduct an additional test on the local virtual machine. For this, the Ubuntu 10.04 LTS guest system was created on VirtualBox, with parameters identical to EC2 MicroInstance (1vCPU, 630MB, 8GB). To get a similar failure rate, I limited the maximum processor load available to the virtual machine at 7% (Intel Core i7 2.8 GHz). Detailed results of this test can be found in this file .

The ratio of the results is similar to the test through CloudFlare.

conclusions

1. The combination of Apache and Nginx recommended in many manuals as reverse proxy will not bring the desired result if your site has few static resources.
2. Apache can successfully compete with Nginx by installing mpm-worker or mpm-event modules instead of the mpm-prefork module.
3. Apache can compete with Nginx even if you use the mpm-prefork module, and you must use php-fpm via fastcgi.
4. If you use the mpm-prefork module, do not forget to limit the number of processes according to the resources of your system.
5. Using CDN CloudFlare at a free tariff does not give a noticeable increase in load capacity. A plus can be considered that in case of complete inaccessibility of the site CloudFlare will give out a saved “snapshot” of the requested page.