table.nginx-blog, table.nginx-blog th, table.nginx-blog td {
边框：2px 纯黑；
边界崩溃：崩溃；
}
表.nginx-博客 {
宽度：100%；
}
table.nginx-blog th {
背景颜色：#d3d3d3；
对齐：左；
左内边距：5px；
右内边距：5px；
底部填充：2px；
顶部填充：2px；
行高：120%；
}
表.nginx-博客 td {
左内边距：5px；
右内边距：5px；
底部填充：2px；
顶部填充：5px；
行高：120%；
}
表.nginx-博客 td.center {
文本对齐：居中；
底部填充：2px；
顶部填充：5px；
行高：120%；
}
缓慢是新的下降趋势 – 根据 Pingdom 的数据，加载时间为 5 秒的网站的跳出率接近 40%。那么这意味着什么呢？如果您的网站需要很长时间才能加载，则近一半的访问者会放弃它并转向其他地方。用户是缺点迫切期望更快的应用程序和更好的数字体验，因此提高性能对于发展业务至关重要。您最不想看到的就是提供市场所需的产品或服务，但缺乏为客户群提供快速、无缝体验的能力。
在这篇文章中，我们分析了两个软件应用程序交付控制器 (ADC)、Avi Vantage 平台和 NGINX 应用程序平台的性能。我们测量客户请求的延迟，这是保持客户参与度的重要指标。
测试协议和收集的指标
我们使用负载生成程序 wrk2 来模拟客户端，在定义的时间段内通过 HTTPS 对文件发出连续请求。接受测试的 ADC 数据平面 – Avi 服务引擎 (SE) 或 NGINX Plus – 充当反向代理，将请求转发到后端 Web 服务器，并将 Web 服务器生成的响应（文件）返回到客户。在各种测试运行中，我们通过改变客户端每秒发出的请求数 (RPS) 以及请求的文件的大小来模拟现实世界的流量模式。
在测试过程中，我们收集了两个性能指标：
- 平均延迟 – 延迟定义为客户端生成请求和接收响应之间的时间量。平均值的计算方法是将测试期间发出的所有请求的响应时间相加，然后除以请求数。
- 第 95 个百分位延迟 – 测试期间收集的延迟测量值按从最高（延迟时间最长）到最低的顺序排序。最高的 5% 会被丢弃，最高的剩余值是第 95 个百分位数的延迟。
测试方法
客户端
我们在 Amazon Elastic Compute Cloud (EC2) 实例上运行以下脚本：
wrk2 -t1 -c50 -d180s -Rx–延迟 https://server.example.com:443/
（有关使用的所有 EC2 实例（包括客户端）的规格，请参阅附录。）为了模拟多个客户端同时访问基于 Web 的应用程序，在每次测试中，脚本生成了一个 wrk2 线程并建立了 50 个连接使用 ADC 数据平面，然后连续请求静态文件 3 分钟（文件大小因测试运行而异）。这些参数对应于以下 wrk2 选项：
- -t 选项 – 要创建的线程数 (1)。
- -c 选项 – 要创建的 TCP 连接数 (50)。
- -d 选项 – 测试期间的秒数（180 或 3 分钟）。
- -Rx 选项 – 客户端每秒发出的请求数（也称为客户端 RPS）。 x 被替换为测试运行的适当客户端 RPS 速率。
- –延迟选项 – 包括每个延迟的详细延迟输出中的百分位信息。
如下所述，我们根据 EC2 实例的大小改变所请求文件的大小：较小的实例为 1 KB，较大的实例为 10 KB 和 100 KB。我们将 1 KB 和 10 KB 文件的 RPS 速率增加了 1,000，将 100 KB 文件的 RPS 速率增加了 100。对于 RPS 速率和文件大小的每种组合，我们总共进行了 20 次测试运行。下图报告了 20 次运行的平均值。
所有请求均通过 HTTPS 发出。我们使用具有 256 位密钥大小和完美前向保密性的 ECC； SSL 密码是 ECDHE-ECDSA-AES256-GCM-SHA384。
Avi 反向代理：配置和版本控制
我们从 AWS Marketplace 部署了 Avi Vantage 版本 17.2.7。 Avi 允许您为 SE 选择 AWS 实例类型，但不能选择底层操作系统。 Avi 控制器预先选择其部署的操作系统s SE；测试时是 Ubuntu 14.04.5 LTS。
NGINX 反向代理：配置和版本控制
与捆绑控制平面（其控制器组件）和数据平面（SE）的 Avi Vantage 平台不同，NGINX 控制平面（NGINX Controller）与数据平面（NGINX Plus）完全解耦。您可以将 NGINX Plus 实例更新到任何版本，或更改为任何支持的操作系统，而无需更新 NGINX Controller。这使您可以灵活地选择可提供最佳性能的 NGINX Plus 版本和操作系统版本，从而使更新变得轻松。利用这种灵活性，我们在 Ubuntu 16.04 上部署了 NGINX Plus R17 实例。
在 NGINX 控制器 GUI 中，我们为 NGINX Plus 反向代理配置了一个可容纳 100 个上游连接的缓存。这通过启用反向代理和上游服务之间的保持活动连接来提高性能呃。
NGINX Plus Web 服务器：配置和版本控制
如前面的拓扑图所示，我们在所有测试中都使用NGINX Plus R17作为Web服务器。
性能结果
t2.medium 实例上的延迟
对于第一个测试，我们在 t2.medium 实例上部署了 Avi SE 和 NGINX Plus。请求的文件大小为 1 KB。该图表在 X 轴上显示客户端 RPS 速率，在 Y 轴上显示以秒为单位的延迟。每个 RPS 速率下的延迟越低越好。
两个延迟测量的结果模式基本相同，仅 Y 轴上的时间刻度不同。通过平均延迟和第 95 个百分位数延迟来衡量，NGINX Plus 提供的 RPS 比 Avi SE 高出近 2.5 倍（6,000 vs. 2,500），然后延迟增加到可以忽略不计的水平。为什么 Avi SE 在如此低的 RPS 率下会导致延迟急剧增加？来回答这个接下来，让我们仔细看看在客户端 RPS 为 2,500 的 Avi SE 上连续 20 次运行的平均延迟和第 95 个百分位延迟的测试。
如下表所示，在 Avi SE 上以 2500 RPS 进行连续 17 次测试时，平均延迟急剧增加到 14 秒以上，而第 95 个百分点的延迟则急剧增加到 35 秒以上。
平均延迟（毫秒）
第 95 个百分位延迟（毫秒）
要了解突然激增的原因，首先要了解 t2 实例是“性能爆发”实例。这意味着它们可以始终消耗可用 vCPU 的基准量（对于我们的 t2.medium 实例为 40%）。当它们运行时，它们还会累积 CPU 积分，每个积分相当于 1 个 vCPU 以 100% 利用率运行 1 分钟。要使用超过其基准 vCPU 分配（突发），实例必须支付积分，当积分耗尽时，实例将被限制回其基准 CPU 分配。
在第 17 次测试运行期间出现延迟峰值后，htop 的输出以详细模式运行，以图形方式显示了限制情况：
标记为 1 和 2 的行对应于 t2.medium 实例的 2 个 CPU，并描述了用于不同用途的每个 CPU 的比例：绿色表示用户进程，红色表示内核进程，等等。我们对青色特别感兴趣，因为它占了总体使用量的大部分。它表示 CPU 窃取时间，在广义虚拟化环境中被定义为“虚拟 CPU 等待真实 CPU 的时间百分比，同时虚拟机管理程序正在为另一个虚拟处理器提供服务”。对于 EC2 可突发性能实例，这是实例因已耗尽 CPU 积分而不允许使用的 CPU 容量。
在 RPS 速率低于 2,500 的情况下，Avi SE 可以完成全部 20 次测试运行，而不会超出其基准分配和 CPU 积分。然而，在 2,500 RPS 下，它在第 17 次测试运行期间耗尽了积分。延迟激增近 10 倍，因为 Avi 无法有效地使用基准 CPU 分配来以与传入请求一样快的速度处理请求。NGINX Plus 使用 CPU 的效率比 Avi SE 高得多，因此它不会耗尽其 CPU 分配和积分直到 6,000 RPS。
c4.large 实例上的延迟
突发性能实例最适合表适用于小型、突发性工作负载，但当 CPU 积分耗尽时，它们的性能会迅速下降。在实际部署中，选择以一致方式消耗 CPU、不会出现 CPU 积分耗尽的实例类型通常更有意义。 Amazon 表示其计算优化实例适用于高性能 Web 服务器，因此我们使用在 c4.large 实例上运行的 Avi SE 和 NGINX Plus 重复了测试。
测试设置和方法与 t2.medium 实例相同，只是客户端请求更大的文件 – 10 KB 和 100 KB，而不是 1 KB。
10 KB 文件的延迟
下图显示了客户端请求 10 KB 文件时的平均延迟和第 95 个百分点的延迟。和以前一样，每个 RPS 速率下的延迟越低越好。
对于 t2.medium 实例的测试，两个延迟测量的结果模式是基本的完全相同，仅 Y 轴上的时间刻度不同。 NGINX Plus 再次优于 Avi SE，超过 70% – 直到大约 7,200 RPS 时才会出现延迟增加，而 Avi SE 在延迟峰值之前只能处理 4,200 RPS。
如下表所示，我们的测试还显示，在每个 RPS 速率下，Avi SE 都会产生比 NGINX Plus 更多的延迟，甚至在达到 Avi SE 延迟激增的 RPS 速率 (4,200) 之前也是如此。在两种产品延迟最接近的 RPS 速率下（2000 RPS），Avi SE 的平均延迟仍然是 NGINX Plus 的 23 倍（54 毫秒对 2.3 毫秒），其第 95 个百分位延迟为 79 倍（317 毫秒对 4.0 毫秒）多发性硬化症）。
在 4000 RPS（略低于 Avi SE 的延迟峰值）时，平均延迟的乘数增长至 69 倍（160 毫秒与 2.3 毫秒），第 95 个百分位延迟的乘数增长至 128 倍（526 毫秒与 4.1 毫秒）。 RPS 高于对于 Avi SE 的延迟峰值，乘数呈爆炸式增长，最大差异为 6,000 RPS：平均延迟为 7666 倍（23 秒与 3.0 毫秒），第 95 个百分点延迟为 8346 倍（43.4 秒与 5.2 毫秒）。
在 NGINX Plus 经历了 7,200 RPS 的延迟峰值后，Avi SE 的性能最接近 NGINX Plus。即便如此，在最佳状态下，Avi SE 的延迟绝不会低于 NGINX Plus 的 2 倍（10,000 RPS 时第 95 个百分位延迟为 93.5 秒，而 45.0 秒）。
平均延迟
第 95 个百分位延迟
NGINX Plus
阿维SE
NGINX Plus
100 KB 文件的延迟
在下一组测试运行中，我们将请求文件的大小增加到 100 KB。
对于这种文件大小，两种产品的 RPS 都大幅下降，但 NGINX Plus 的性能仍然优于 Avi SE，接近 40% – NGINX Plus 直到大约 720 RPS 才会出现明显增加的延迟，而 Avi SE 只能处理 520 RPS在延迟峰值之前。
对于 10 KB 文件的测试，Avi SE 在每个 RPS 速率下也会比 NGINX Plus 产生更多的延迟。下表显示乘数不像 10 KB 文件那么大，但仍然很稳定ll 显着。 Avi SE 峰值之前的最低乘数为 17 倍，平均延迟为 400 RPS（185 毫秒与 10.7 毫秒）。
平均延迟
第 95 个百分位延迟
NGINX Plus
阿维SE
NGINX Plus
c4.large 实例上的 CPU 使用率
我们的最终测试重点是 Avi SE 和 NGINX Plus 在 c4.large 实例上的总体 CPU 使用情况。我们使用 10 KB 和 100 KB 进行了测试文件。
对于 10 KB 文件，Avi SE 在大约 5,000 RPS 时达到 100% CPU 使用率，NGINX Plus 在大约 8,000 RPS 时达到 100% CPU 使用率，这意味着 NGINX Plus 的性能提高了 60%。对于这两种产品，CPU 使用率达到 100% 与延迟峰值之间存在明显的相关性，延迟峰值发生在 Avi SE 为 4,200 RPS 时，NGINX Plus 为 7,200 RPS 时。
对于 100 KB 文件，结果更加惊人。 Avi SE 最多处理 520 RPS，因为此时它的 CPU 使用率达到 100%。 NGINX Plus 的性能提高了近 40%，最高速率为 720 RPS*。但请注意，NGINX Plus 此时使用的可用 CPU 不到 25% – 速率上限为 720 RPS，不是因为 NGINX Plus 中的处理限制，而是因为测试环境中的网络带宽限制。与 Avi SE 相比，Avi SE 最大化了 EC2 实例上的 CPU至此，NGINX Plus 提供了可靠的性能，并且仍有大量 CPU 周期可用于实例上运行的其他任务。
* 该图表显示最大值为 600 和 800 RPS，但这是图形软件的产物 – 我们以 100 RPS 的增量进行测试，并且在以这些速率进行测试运行期间出现了最大值。
摘要
我们在实际测试案例中对 NGINX 和 Avi Vantage 进行了广泛测试，其中客户端持续生成流量大约 12 小时，请求率稳步提高。
结果可总结如下：
-
NGINX 更有效地使用 CPU，从而减少延迟。
- 在突发性能实例（我们测试中的 t2.medium）上运行时，Avi 比 NGINX 更快地耗尽 CPU 积分余额。
- 在稳定的实例上运行，没有 CPU 信用限制（我们的测试中为 c4.large），并且在繁重、恒定的客户端负载下运行，NGINX 在遇到延迟峰值之前处理了更多 RPS – 10 KB 文件的 RPS 大约增加了 70%，100 KB 文件的 RPS 大约增加了 40%。
- 对于 100 KB 文件，100% CPU 使用率与 Avi 可以处理的峰值 RPS 直接相关。相比之下，NGINX Plus 从未达到 100% CPU – 相反，它仅受可用网络带宽的限制。
- 在 c4.large 实例上的每次延迟测试中，NGINX 的表现均优于 Avi，即使 RPS 速率低于 Avi 延迟峰值的水平也是如此。
正如我们之前提到的，Avi Vantage 不允许您为 Avi SE 实例选择操作系统。因此，如果操作系统中发现安全漏洞，您将无法升级到操作系统供应商提供的补丁版本；您必须等待 Avi 发布修复安全问题的新版本 Avi Controller。这可能会让您的所有应用程序暴露在强大的威胁之下通常周期较长。
附录：Amazon EC2 规格
这些表总结了测试环境中使用的 Amazon EC2 实例的规格。
在每种情况下，实例都位于同一 AWS 区域。
在 t2.medium 实例上测试
实例类型
vCPU
内存（GB）
在 c4.large 实例上测试
实例类型
vCPU
内存（GB）
发表回复