In this article, we will try our hand at reverse engineering, one might say. We will peek under the hood of each of the web servers with our dirty hands, exploiting them in a way that no one would ever exploit.
This test is a measurement of a spherical horse in a vacuum, nothing more than the data that was received, and now we do not know what to do with it.
Method
The operating system for Nginx and Apache is Ubuntu 18.04 LTS, for IIS Windows Server Core 2019. Before the tests, all operating systems received the latest updates as of 04.12.2019/XNUMX/XNUMX.
Tests were conducted exclusively over HTTP. Each of the web servers was running the same page, a free Jekyll template from Codrops. . Gzip compression was disabled on each of the web servers.
Throughput test was done with Httpd-tools with arguments:
ab -n 50000 -c 500 http://192.168.76.204:80/Servers were limited to 10, 5, and 1 percent of the core on 8, 4, and one core. The test bench was a computer with 9900K@5400MHz, which means that the server receiving a 10% limit receives about 540MHz per core.
The TTFB test was carried out at the first server boot and measured using DevTools, after receiving the result, the server turned off and rolled back to the previous checkpoint to exclude any kind of caches.
The tester and the web server were on the same host and on the same virtual switch.
To immediately evaluate the disk subsystem, the results of the ATTO and CrystalDIskMark benchmark to have an idea of ββββbottlenecks.
Data taken from the virtual machine:
Results:
TTFB:
The average TTFB for IIS is the smallest, 0,5ms, versus 1,4ms for Apache and 4ms for Nginx.
Throughput:
First, consider how well each of the servers scales in terms of the number of cores.
The graph shows the number of tester's calls to the web server and latency. The graph shows that NGINX completed 98% of all requests, giving the site in 20ms or less. IIS, like Apache, completed the last 5% of all requests in 76ms and 14ms, respectively.
The graph shows the average processing time per request during a stress test.
As you can see from the graphs, IIS blew both Apache and Nginx, slowing down a lot under high load.
IIS clearly favored 4 cores over XNUMX, showing lower latencies at XNUMX, but didn't approve of one core much either.
NGINX scales nicely across all 8 cores, and for Apache, the single-core scenario seems to be the best choice.
Scalability:
NGINX:
Now consider scalability in terms of frequency and number of cores.
Tests with a limit of 1% for 4 and 1 Nginx cores did not pass, having gone beyond 2000 requests, it terminated the connection with the tester.
Apache:
Apache like Nginx after processing 2500 requests gave up and dropped the connection. Apache failed the test on 8, 4 and 1 cores with a limit of 1%, but it also failed the test on a 5% limit on one core, which is worse than Nginx
US;
IIS ran a huge queue of requests during the tests, but it processed every one of them. Apparently, it does not set timeouts for request processing out of the box.
The diagram shows the time for which the test was completed. Absolutely absurd test configurations were discarded. From the diagram you can see how IIS is demanding on hardware, and how wonderful NGINX is.
Scalability from disk:
NGINX:
Now consider scalability in terms of frequency and number of cores and disk speed.
This time Nginx failed 4 tests instead of XNUMX.
Apache:
Apache failed the same number of tests as last time.
US;
IIS shows an almost identical graph, as if there were no disk limits. In general, the schedules of all servers have not changed much, which means that each of them cached statics into RAM and gave back from there. Here we see the main bottleneck - the web server itself.
It is too early to draw conclusions based on this testing, we have not yet tested HTTPS, compression and HTTP / 2 with a live certificate from Let's Encrypt. We will talk about this in the next article.
Source: habr.com