有人可能会说，在本文中，我们将尝试进行逆向工程。 我们用肮脏的双手望着每台Web服务器的身影，以前所未有的方式利用它们。
该测试是在真空中对球形马的测量，仅是接收到的数据，现在我们不知道如何处理它们。
方法论
Nginx和Apache的操作系统是IIS Windows Server Core 2019的Ubuntu 18.04 LTS。测试之前的所有操作系统均于2019年12月4日收到最新更新。
测试仅通过HTTP进行。 每个Web服务器都有相同的页面，这是Codrops提供的Jekyll的免费模板。
友情链接 在每个Web服务器上，gzip压缩均已关闭。
带宽测试是使用带有参数的Httpd工具进行的：
ab -n 50000 -c 500 http://192.168.76.204:80/
将服务器的限制分别设置为8、4和1个核心的10％，5％和1％。 作为测试平台，有一台计算机在9400K @ 5400 MHz下运行，这意味着接收10％限制的服务器每个内核可获得约540 MHz。
TTFB测试是在服务器首次启动时进行的，并使用DevTools进行了测量，接收到结果后，服务器将关闭电源并回滚到先前的控制点以排除任何类型的缓存的出现。
测试仪和Web服务器位于同一主机和同一虚拟交换机上。
为了立即评估磁盘子系统，可以通过ATTO和CrystalDIskMark基准测试的结果来了解瓶颈。
结果：
TTFB：
IIS的平均TTFB最小，为0.5毫秒，而Apache的平均TTFB为1.4毫秒，Nginx的平均为4毫秒。吞吐量：首先，考虑每个服务器在核心数量方面的扩展程度。
该图显示了测试人员调用Web服务器的次数和延迟。 该图显示，NGINX完成了所有点击的98％，使网站停留了20毫秒或更短的时间。 IIS和Apache的最后5％的呼叫分别工作了76ms和14ms。
该图显示了压力测试期间一个请求的平均处理时间。
从图中可以看到，IIS导致Apache和Nginx都崩溃了，在高负载下速度大大降低。
IIS显然比四个核心更喜欢四个核心，这显示四个核心上的延迟较少，但也没有强烈支持一个核心。
NGINX可以完美地扩展到所有8个内核，对于Apache来说，似乎单核脚本似乎是最佳选择。
可扩展性：
Nginx：现在考虑核心频率和数量上的可伸缩性。
Nginx在4个和1个内核上的限制为1％的测试未通过，留下了2000个请求，它与测试器断开了连接。
阿帕奇：处理了2500个请求后，作为Nginx的Apache投降并断开了连接。 Apache未能通过限制为1％的8、4和1个内核的测试，但是此外，一个内核的5％限制的测试没有通过，这比Nginx差。
IIS：在测试期间，IIS收集了大量的请求队列，但处理了每个请求。 显然，没有在其中设置用于处理请求的开箱超时。
该图显示了完成测试所需的时间。 荒唐荒谬的测试配置被删除。 该图显示了IIS对硬件的要求以及NGINX的美观程度。
磁盘可伸缩性：
Nginx：现在考虑频率，内核数和磁盘速度的可伸缩性。
这次Nginx未能通过4次测试，而不是两次。
阿帕奇：Apache失败的测试次数与上次相同。
IIS：IIS显示几乎完全相同的图，就好像没有磁盘限制一样。 通常，所有服务器的图形变化不大，这意味着它们中的每一个都将静态数据缓存到RAM中并从那里提供。 在这里，我们看到了主要瓶颈-Web服务器本身。
根据此测试得出结论还为时过早；我们尚未使用Let's Encrypt提供的实时证书测试HTTPS，压缩和HTTP / 2。 我们将在下一篇文章中讨论。
我们提供了已更新的UltraLite
Windows VDS关税，已安装Windows Server 2019 Core的价格为99卢布。
