我们讨论了方法论 在这篇文章中，我们在更现实的场景中测试 HTTPS。 为了进行测试，我们获得了 Let's Encrypt 证书并启用了 Brotli 压缩至 11。
这次我们将尝试重现在 VDS 上部署服务器或在具有标准处理器的主机上作为虚拟机部署服务器的场景。 为此，设置了一个限制：
- 25% - 相当于 ~ 1350 MHz 的频率
- 35%-1890MHz
- 41% - 2214 兆赫
- 65% - 3510 兆赫
一次性连接数从500个减少到1、3、5、7、9个，
结果：
延误：
TTFB 被专门作为单独的测试包含在内，因为 HTTPD 工具会为每个单独的请求创建一个新用户。 这个测试仍然脱离现实，因为用户仍然会点击几个页面，而实际上 TTFP 将扮演主要角色。
第一个（通常是 IIS 虚拟机首次启动后的第一个请求）平均需要 120 毫秒。
所有后续请求均显示 TTFP 为 1.5 毫秒。 Apache 和 Nginx 在这方面落后。 就我个人而言，作者认为这个测试最具启发性，并且只会根据它来选择获胜者。
结果并不奇怪，因为 IIS 缓存了已经压缩的静态内容，并且不会在每次访问时对其进行压缩。
每个客户花费的时间
要评估性能，使用 1 个连接进行测试就足够了。
例如，IIS在5000秒内完成了40个用户的测试，即每秒123个请求。
下图显示了网站内容完全传输所需的时间。 这是在给定时间内完成的请求的比例。 在我们的案例中，80% 的所有请求在 IIS 上的处理时间为 8 毫秒，在 Apache 和 Nginx 上的处理时间为 4.5 毫秒，而 Apache 和 Nginx 上的所有请求中有 8% 在最多 98 毫秒的时间间隔内完成。
处理 5000 个请求的时间：
处理 5000 个请求的时间：
如果您的虚拟机具有 3.5GHz CPU 和 8 核，则选择您想要的。 在此测试中，所有 Web 服务器都非常相似。 我们将在下面讨论为每个主机选择哪个 Web 服务器。
当涉及到稍微更现实的情况时，所有网络服务器都会正面交锋。
速率：
延迟与同时连接数的关系图。 越平滑、越低越好。 最后 2% 已从图表中删除，因为它们会使图表变得难以阅读。
现在让我们考虑将服务器托管在虚拟主机上的选项。 我们以 4 GHz 的 2.2 个核心和 1.8 GHz 的 XNUMX 个核心为例。
如何扩展
如果您曾经见过真空三极管、五极管等的电流-电压特性，那么您会对这些图表感到熟悉。 这就是我们想要抓住的——饱和度。 限制是无论你投入多少个核心，性能的提升都不会很明显。
以前，整个挑战是以所有请求的最低延迟处理 98% 的请求，并尽可能保持曲线平坦。 现在，通过构建另一条曲线，我们将找到每个服务器的最佳工作点。
为此，我们采用每秒请求数 (RPR) 指标。 水平是频率，垂直是每秒处理的请求数，行数是核心数。
显示 Nginx 处理一个又一个请求的效果的相关性。 8核在本次测试中表现更好。
该图清楚地显示了 Nginx 在单核上的工作效果有多好（不是很多）。 如果您有 Nginx，并且仅托管静态内核，则应考虑将内核数量减少到 XNUMX。
尽管根据 Chrome 中的 DevTools 的数据，IIS 的 TTFB 最低，但在与 Apache 基金会的压力测试的激烈竞争中，IIS 却输给了 Nginx 和 Apache。
图表的所有曲率都被铁定再现。
某种结论：
是的，Apache 在 1 核和 8 核上表现较差，但在 4 核上表现稍好一些。
是的，8 核上的 Nginx 在 1 核和 4 核上处理一个接一个的请求效果更好，但当有很多连接时，效果会更差。
是的，对于多线程工作负载，IIS 更喜欢 4 个核心，对于单线程工作负载，IIS 更喜欢 8 个核心。 最终，尽管所有服务器都处于同等水平，但在高负载下，IIS 在 8 核上的速度比其他服务器稍快。
这不是测量误差，这里的误差不超过+-1ms。 延迟且 RPR 每秒不超过 +- 2-3 个请求。
8 个核心性能较差的结果一点也不奇怪，如果我们有一个必须完成整个管道的时间范围，许多核心和 SMT/超线程会极大地降低性能。
来源： habr.com