WEB 服务器之战。 第 1 部分 – HTTP 脱节：

有人可能会说，在本文中，我们将尝试进行逆向工程。 我们将把我们的脏手藏在每台网络服务器的引擎盖下，以任何人都不会利用的方式利用它们。

这个测试是在真空中对球形马的测量，只不过是获得了数据，现在我们不知道如何处理它。

技术

Nginx 和 Apache 的操作系统是 Ubuntu 18.04 LTS，适用于 IIS Windows Server Core 2019。在测试之前，所有操作系统都收到了截至 04.12.2019 年 XNUMX 月 XNUMX 日的最新更新。

测试仅通过 HTTP 进行。 每个 Web 服务器都运行相同的页面，即 Codrops 提供的免费 Jekyll 模板。 链接。 每个 Web 服务器都禁用了 gzip 压缩。

吞吐量测试是使用 Httpd-tools 完成的，参数如下：

ab -n 50000 -c 500 http://192.168.76.204:80/

服务器在 10、5 和 1 个核心上被限制为 8%、4% 和 9900% 的核心。 测试台是一台 5400K@10MHz 的计算机，这意味着接收 540% 限制的服务器每个核心接收约 XNUMXMHz。

TTFB测试是在服务器首次启动时进行的，并使用DevTools进行测量；收到结果后，关闭服务器并回滚到之前的检查点，以消除任何类型缓存的出现。

测试仪和 Web 服务器位于同一主机和同一虚拟交换机上。

要立即评估磁盘子系统、ATTO 和 CrystalDIskMark 基准测试的结果，以便了解瓶颈。

从虚拟机获取的数据：

结果：

TTFB：

IIS 的平均 TTFB 最小，为 0,5 毫秒，而 Apache 为 1,4 毫秒，Nginx 为 4 毫秒。

速率：

首先，让我们看看每台服务器根据内核数量进行扩展的效果如何。

该图显示了测试人员对 Web 服务器的调用次数和延迟。 该图显示 NGINX 处理了 98% 的请求，在 20 毫秒或更短的时间内交付了站点。 IIS 与 Apache 一样，分别在 5 毫秒和 76 毫秒内完成了最后 14% 的调用。

该图显示了压力测试期间一个请求的平均处理时间。

从图中可以看出，IIS 击败了 Apache 和 Nginx，在高负载下速度显着减慢。 

IIS 显然更喜欢 4 核而不是 XNUMX 核，显示 XNUMX 核的延迟较低，但也不太喜欢 XNUMX 核。

NGINX 在所有 8 个核心上都能很好地扩展，对于 Apache 来说，单核场景似乎是最佳选择。

可扩展性：

Nginx：

现在让我们看看频率和核心数量方面的可扩展性。 

Nginx 没有通过 1 核和 4 核 1% 限制的测试；当超过 2000 个请求时，它终止了与测试器的连接。

阿帕奇：

Apache 和 Nginx 一样，在处理了 2500 个请求后，放弃并关闭了连接。 Apache 在 8、4 和 1 核限制为 1% 的测试中均未通过，此外它在 5 核限制为 XNUMX% 的测试中也未通过测试，这比 Nginx 还差

IIS：

在测试期间，IIS 积累了一个巨大的请求队列，但处理了每个请求。 显然，开箱即用的请求处理没有超时设置。

该图表显示了完成测试所需的时间。 完全荒谬的测试配置被丢弃。 从图中可以看出IIS对硬件的要求有多么高，以及NGINX有多么的出色。

从磁盘的可扩展性：

Nginx：

现在让我们看看频率、核心数量以及磁盘速度方面的可扩展性。 

这次 Nginx 失败了 4 次测试，而不是两次。

阿帕奇：

Apache 未通过的测试数量与上次相同。

IIS：

IIS 显示几乎相同的图表，就好像没有磁盘限制一样。 总的来说，所有服务器的图形都没有太大变化，这意味着每个服务器都将静态数据缓存在 RAM 中并从那里提供服务。 在这里我们看到了主要的瓶颈——网络服务器本身。

根据此测试得出结论还为时过早；我们尚未使用 Let's Encrypt 的实时证书测试 HTTPS、压缩和 HTTP/2。 我们将在下一篇文章中讨论这个问题。

来源： habr.com