对 NGINX、Kong 和 Amazon 的 API 管理解决方案进行基准测试： 他们是否实时提供 API？

速度——这是当今数字环境中的关键，如果您的应用性能太慢，消费者很容易转向竞争对手。 应用程序速度最终取决于响应迅速、健康且适应性强的 API，而 API 响应能力的关键因素之一是 API 网关引入的延迟。 但并非所有 API 网关的性能都达到同一水平。

去年秋天，一位 NGINX 客户（消费信贷行业的主要参与者）告诉我们，“实时”API 性能的重要性日益增加，因为越来越多的应用程序和其他组件需要进行通信以提供用户期望的数字体验，这让我们深刻地认识到了这一点。 我们非常高兴地得知 NGINX Plus 是唯一实现客户所需的超快 API 延迟（低至 10 毫秒（ms））的 API 网关。 许多其他客户，例如Capital One ，也与我们分享了如何使用 NGINX Open Source 或 NGINX Plus 作为其 API 网关来减少延迟并提高吞吐量。

我们决定深入研究 API 生态系统，并尝试找出是什么让 API 变得“实时”。 基于多种因素，我们确定实时 API 必须在 30 毫秒内以端到端的方式处理第 99 个百分位之前的每一个 API 调用（这意味着平均每 100 个调用中只有 1 个调用需要的时间超过 30 毫秒）。

比较 API 管理解决方案

我们自己的测试一致表明，使用我们的 API 管理解决方案可以轻松实现实时 API 性能，该解决方案结合了NGINX Plus作为处理 API 调用的 API 网关，以及NGINX 控制器 API 管理模块，用于在定义、发布、管理和监控整个生命周期内管理 NGINX Plus 实例和 API。

但我们明白您可能不愿意相信我们的说法。 因此，我们委托了独立技术研究和分析公司GigaOm对我们的 API 管理解决方案和市场上其他流行解决方案进行客观透明的基准测试：两种像 NGINX 一样可以在本地或云端部署的解决方案Apigee和Kong Enterprise ，以及两种完全托管的云产品Amazon API Gateway和 Kong Cloud。

在这篇博客中，我们总结了 GigaOm 的测试结果（剧透： NGINX Plus 在每种测试条件下都实时提供 API，而其他解决方案则没有）。 有关解决方案、测试方法和结果的所有详细信息，请联系我们团队的成员。

笔记： Apigee 最终用户许可协议 (EULA) 禁止在未经 Google 明确许可的情况下发布测试结果，因此遗憾的是该报告和本博客均不包含有关 Apigee 的信息。

基准概述

GigaOm 使用Vegeta HTTP 负载测试工具来生成请求（API 调用），并测量了 API 网关在不同每秒请求数（RPS）下引入的延迟（返回 API 调用响应所需的时间），GigaOm 将其称为“攻击率”。 GigaOm 进行了测试，攻击率从 1,000 RPS 开始，逐渐增加到 5,000、10,000、20,000 等等，直到 Vegeta 报告错误状态代码。 每次测试持续 60 秒，重复 3 次。 如下图所示，GigaOm 捕获了第 50、90、95、99、99.9 和 99.99 百分位数的延迟，并记录了测试运行期间观察到的最长延迟（图表中的最大值）。

结果： NGINX 与 香港企业

GigaOm 进行了两项基准测试，比较了 NGINX Plus（使用 NGINX Controller 部署）和 Kong Node（使用 Kong Enterprise 部署）。 在第一个基准测试中，有一个工作节点（一个 NGINX Plus 或 Kong Node 实例）。 第二种方法是，有三个工作节点通过 NGINX Open Source 以循环模式进行负载平衡。 （GigaOm 强调，使用 NGINX Open Source 作为负载均衡器并没有为 NGINX Plus 带来优势，甚至 Kong 也建议将其用作集群 Kong Node 实例的负载均衡器。）

如下图所示，NGINX 和 Kong 之间的延迟差异在第 99 百分位之前可以忽略不计，此时 Kong 的延迟开始呈指数增长。 在 99.99 百分位，Kong 的延迟在两个基准测试中分别是 NGINX 的三倍或两倍。

第 99 个百分位数是将 API 定义为实时的适当最小值，但 GigaOm 指出，在实际部署中，在第 99.9 个和第 99.99 个百分位数等较高百分位数保持低延迟“极其重要”。 该报告解释道：

延迟结果随着时间的推移趋于多模式，尖峰的顶部表示响应时间的“中断”。

这些小问题很重要。 如果平均响应时间或延迟小于 30 毫秒，但出现 1 秒或更长的延迟，则实际上会对后续用户体验产生累积效应。 例如，如果您去一家快餐店，那里的食物平均等待时间为 1 分钟，您可能会认为这是一次良好的顾客体验。 但是，如果您前面的顾客对订单有问题，而且需要 10 分钟才能解决，该怎么办？ 您的等待时间实际上为 11 分钟。 由于您的请求是在出现故障后才排队的，因此延迟的 99.99 百分位的延迟也可能成为您的延迟。

在分布式应用中，单个客户端请求实际上可能会产生多个下游 API 调用，因此高百分位数异常大的延迟的负面影响变得更加明显。 例如，假设 1 个客户端请求会对子系统创建 10 个 API 调用，且响应缓慢的概率为 1%。 从数学上可以证明，1 个客户端请求受到缓慢响应影响的概率几乎为 10%。 有关数学的详细信息，请参阅谁移动了我的第 99 个百分位延迟？

图 1 描绘了单个工作节点 30,000 RPS 攻击率的结果。 在 99.99 百分位，Kong 的延迟是 NGINX 的 3 倍多，并且超过了实时 API 30 毫秒的阈值。 相比之下，NGINX Plus 在每个百分位都实现了实时延迟 - 即使其最高记录（最大）延迟 13 毫秒也不到实时阈值的一半。

图 2 显示了具有三个工作节点的基准测试的非常相似的结果，攻击速率也是 30,000 RPS。 有趣的是，Kong 在 99 和 99.9 百分位上的表现优于 NGINX，但在 99.99 百分位上再次遭遇巨大的延迟峰值，这次的延迟大约是 NGINX 的两倍。 与第一个基准测试一样，NGINX 在所有百分位数上都保持在 30 毫秒实时阈值以下。

衡量 API 网关性能的另一种方法是确定它可以 100% 成功处理的最大 RPS（无5xx或429对于单节点和三节点配置，所有百分位数的[请求过多]错误和低于 30 毫秒的延迟。 图 3 显示了通过这种措施，NGINX 的 RPS 比 Kong 高出 50％： 30,000 对 20,000。

结果： NGINX 与 Kong Cloud 和 Amazon API Gateway

在第三组基准测试中，GigaOm 将 NGINX Plus 与 Kong Cloud 和 Amazon API Gateway 进行了比较。 GigaOm 强调，直接比较是非常成问题的，因为 Kong Cloud 和 Amazon API Gateway 是完全托管的 SaaS 产品，而 NGINX Controller 是 PaaS 产品，目前不作为 SaaS 提供。 具体来说，这两种 SaaS 产品都没有透露其使用的实例类型、计算能力、内存或网络功能。 因此，GigaOm 必须对 NGINX Plus 的类似设置做出最佳猜测。

即使不与 NGINX Plus 进行比较，我们也可以立即发现，SaaS 产品无法在任何测试百分位数下实时提供 API，即使在图 4 所示的第二低攻击率（5,000 RPS）下也是如此。 在第 50 个百分位，SaaS 产品的延迟已经是 30 毫秒阈值的 7 倍多；在第 99.99 个百分位，它超过该阈值超过 8000%。 显而易见的含义是，在任何情况下，Kong Cloud 或 Amazon API Gateway 都无法将延迟控制在 30 毫秒以下，从而实现 100% 的成功率。

验证 NGINX 是唯一的实时 API 解决方案

总而言之，NGINX 是 GigaOm 测试的唯一符合实时 API 处理标准的解决方案，每个百分位的延迟都小于 30 毫秒。 Kong Enterprise 在 99 百分位达到了实时性能，但其延迟在更高百分位时会显著增加，因此它不适合需要中等量实时 API 处理的生产环境。 所测试的 SaaS 解决方案都不能归类为实时解决方案。

GigaOm 报告验证了我们之前的基准以及我们从客户那里听到的信息。 NGINX Plus 是市场上最快的 API 网关，也是唯一能够在所有百分位数上维持低于 30 毫秒的延迟的 API 解决方案。 如果将它与 NGINX Controller 配对，您将获得一个独特架构的 API 管理解决方案，由于仔细的解耦，API 网关数据平面（NGINX Plus）与 API 管理控制平面（NGINX Controller）的性能不会受到任何影响。

您可以使用我们的rtapi延迟测量工具测试您自己的 API 性能。 查看并与我们联系，讨论我们如何帮助您使您的 API 实时化。