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 them.
Methodology
The operating system for Nginx and Apache is Ubuntu 18.04 LTS, for IIS Windows Server Core 2019. All operating systems before the tests received the latest updates on 04/04/2019.
Tests were conducted exclusively over HTTP. Each web server had the same page, a free template for Jekyll from Codrops. Link On each of the web servers gzip compression was turned off.
The bandwidth test was conducted with Httpd-tools with arguments:
ab -n 50000 -c 500 http://192.168.76.204:80/
The servers set a limit of 10, 5 and 1 percent of the core on 8, 4 and one core. As a test bench, there was a computer with 9900K @ 5400 MHz, which means that the server, which received a 10% limit, gets about 540 MHz per core.
The TTFB test was carried out at the first boot of the server and was measured using DevTools, after receiving the result, the server turned off and rolled back to the previous checkpoint to exclude the appearance of any kind of cache.
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 benchmarks to understand the bottlenecks.
Data taken from the virtual machine: 
Results:
TTFB:
The average TTFB for IIS is the least, 0.5ms, versus 1.4ms for Apache and 4ms for Nginx.
Throughput:
First, consider how well each server scales in terms of the number of cores.
The graph shows the number of tester calls to the web server and latency. The graph shows that NGINX fulfilled 98% of all hits, giving the site for 20ms or less. IIS as well as Apache last 5% of all calls worked for 76ms and 14ms, respectively.
The graph shows the average processing time for one request during a stress test.
As you can see from the graphs, IIS blew both Apache and Nginx, slowing down very much under heavy load.
IIS clearly preferred 4 cores over eight, showing less delays on four, but also did not strongly endorse one core.
NGINX scales perfectly to all 8 cores, and for Apache, it seems that a single-core scenario seems to be the best choice.
Scalability:
Nginx:
Now consider scalability in frequency and number of cores.
Tests with a limit of 1% on 4 and 1 kernels Nginx did not pass, leaving 2000 requests, he disconnected from the tester.
Apache:
Apache as Nginx after processing 2500 requests surrendered and disconnected. Apache did not pass the test on 8, 4, and 1 kernels with a limit of 1%, but in addition, the test at the 5% limit on one core did not pass, which is worse than Nginx
IIS:
IIS during the tests gathered a giant queue of requests but processed each of them. Apparently, the timeouts for processing the request are not set in it out of the box.
The diagram shows the time taken to complete the test. Absurdly absurd test configurations were dropped. The diagram shows how IIS is demanding on hardware, and how beautiful NGINX is.
Disk scalability:
Nginx:
Now consider scalability in frequency and number of cores and disk speed.
This time Nginx failed 4 tests, instead of two.
Apache:
Apache failed the same number of tests, as last time.
IIS:
IIS shows an almost identical graph, as if there were no disk restrictions. In general, the graphs of all servers have not changed much, which means that each of them cached the statics into RAM and gave them from there. Here we see the main bottleneck - the web server itself.
It’s too early to draw conclusions on the basis of 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.
