对 NGINX、Kong 和 Amazon 的 API 管理解决方案进行基准测试:它们能否交付实时 API?

原文作者:Alessandro Fael Garcia of F5

原文链接:对 NGINX、Kong 和 Amazon 的 API 管理解决方案进行基准测试:它们能否交付实时 API?

转载来源:NGINX 开源社区


NGINX 唯一中文官方社区 ,尽在 nginx.org.cn

速度 — 这在当今数字环境中尤为重要,如果您的应用性能太慢,消费者会毫不犹豫地选择您的竞争对手。应用速度最终取决于 API 的响应能力、运行状况和适应性,而影响 API 响应能力的关键因素之一就是 API 网关引入的延迟。但是,并非所有 API 网关的性能都是相同水平。

这点让我想起去年秋天,一位 NGINX 客户(消费信贷行业的一家知名公司)告诉我们,随着越来越多的应用和其他组件需要彼此通信以提供用户期望的数字体验,“实时” API 性能的重要性正日益提高。我们很高兴得知 NGINX Plus 是唯一能实现客户所需的超短 API 延迟(低至 10 毫秒)的 API 网关。其他许多客户,例如 Capital One,也与我们分享了如何通过使用 NGINX 开源版或 NGINX Plus 作为 API 网关来缩短延迟和提高吞吐量。

我们决定对 API 生态系统进行更深入的研究,并尝试弄清 API “实时”意味着什么。基于大量的考虑因素,我们最终确定了实时 API 处理端到端 API 调用的时间,前 99 百分位必须在 30 毫秒内(这意味着平均只有百分之一的调用用时超过 30 毫秒)。

比较 API 管理解决方案

我们的内部测试一致表明,当您定义、发布 API 并进行全生命周期管理和监控时,通过我们的 API 管理解决方案可以轻松实现实时 API 性能,该解决方案将 NGINX Plus 用作处理 API 调用的 API 网关,并使用 NGINX Controller API 管理模块(现已并入 NGINX Management Suite)来管理两个 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 调用),并测量了在各种吞吐率 (RPS) 下 API 网关引入的延迟,即将响应返回给 API 调用所花费的时间。GigaOm 将 RPS 称为“攻击速率”。GigaOm 在从 1,000 到 5,000、10,000、20,000 及更高 RPS 的攻击速率下,不断运行测试,直到 Vegeta 报告错误状态代码为止。每次测试持续 60 秒,并重复 3 次。如下图所示,GigaOm 捕获了在 50、90、95、99、99.9 和 99.99 百分位下的延迟,并且还记录了在测试运行期间观察到的最长延迟(即图中的最大)。

结果:NGINX 与 Kong Enterprise

GigaOm 进行了两次基准测试,对 NGINX Plus(使用 NGINX Controller 部署)和 Kong Node(使用 Kong Enterprise 部署)进行了比较。在第一次基准测试中,只有一个工作节点(一个 NGINX Plus 或 Kong Node 实例)。在第二次基准测试中,3 个工作节点由 NGINX 开源版通过轮询调度算法进行负载均衡。(GigaOm 强调,使用 NGINX 开源版作为负载均衡器并不会给 NGINX Plus 带来优势,甚至 Kong 建议将其用作集群 Kong 实例的负载均衡器。)

如下图所示,在第 99 百分位之前,NGINX 和 Kong 之间的延迟差异可以忽略不计,但之后 Kong 的延迟开始呈指数增长。在两次基准测试中,在第 99.99 百分位下,Kong 的延迟均为 NGINX 的两倍或三倍。

API 在每个百分位下,直到第 99 百分位为止都能保持低延迟才能被定义为实时,但 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 毫秒,还不到实时阈值的一半。

图 1.在单节点和 30,000 RPS 下的 NGINX Controller(现已并入 NGINX Management Suite)和 Kong Enterprise

图 2 显示了在三个工作节点下,同样也是在 30,000 RPS 攻击速率下的基准测试结果。有趣的是,在第 99 百分位和第 99.9 百分位下,Kong 表现优于 NGINX,但到第 99.99 百分位再次经历了延迟飙升,这时的延迟大约是 NGINX 的两倍。与第一个基准测试一样,NGINX 在所有百分位均保持小于 30 毫秒的实时阈值。

图 2.在三节点和 30,000 RPS 下的 NGINX Controller(现已并入 NGINX Management Suite)和 Kong Enterprise

衡量 API 网关性能的另一种方法是,利用单节点和三节点配置,确定在百分百成功(无 5xx 或 429 [Too Many Requests] 错误)并且在所有百分位延迟都小于 30 毫秒的情况下,它可以处理的最大 RPS。图 3 显示了根据此测量方法,NGINX 支持比 Kong 高出 50% 的 RPS:30,000 VS. 20,000。

图 3.无误情况下实现的最大吞吐量

结果:NGINX 与 Kong Cloud 和 Amazon API Gateway

在第三组基准测试中,GigaOm 将 NGINX Plus 同 Kong Cloud 和 Amazon API Gateway 进行了比较。GigaOm 强调,直接比较存在很大问题,因为 Kong Cloud 和 Amazon API Gateway 是完全托管的 SaaS 产品,而 NGINX Controller(现已并入 NGINX Management Suite)是 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 毫秒的延迟。

图 4.在单节点和 5,000 RPS 下的 NGINX Controller(现已并入 NGINX Management Suite)、Amazon API Gateway 及 Kong Cloud

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

总而言之,NGINX 是业经 GigaOm 测试的唯一符合实时 API 处理标准的解决方案,在每个百分位下的延迟均小于 30 毫秒。Kong Enterprise 在第 99 百分位获得了实时性能,但在较高的百分位下,其延迟急剧上升。因此,它不适合即便是只需适量实时 API 处理的生产环境。测试中的 SaaS 解决方案均不能被归类为实时。

GigaOm 报告证实了我们以前的基准测试结果以及客户向我们提供的反馈。NGINX Plus 是市场上最快的 API 网关,并且是唯一能够在所有百分位下都保持小于 30 毫秒延迟的 API 解决方案。而且,如果将其与 NGINX Controller (现已并入 NGINX Management Suite)搭配使用,您将可以获得具有独特架构的 API 管理解决方案。通过精心的解耦设计,API 管理控制平面 (NGINX Controller,现已并入 NGINX Management Suite) 不会对 API 网关数据平面 (NGINX Plus) 的性能产生任何影响。

您可以使用我们的 rtapi 延迟测量工具测试您自己的 API 性能。请联系我们,探讨我们可如何帮助您实现实时 API。


NGINX 唯一中文官方社区 ,尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源: 开源社区官网 | 微信公众号

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/588679.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【Qt】使用Qt实现Web服务器(九):EventSource+JSON实现工业界面数据刷新

1、效果 效果如下,实时刷新温度、湿度 2、源码 2.1 index.html <html><body> <!-- 页面布局,本人对HTML标签不熟悉,凑合看吧 --> <div><label for

智能交通广播系统解决方案

智能交通广播系统解决方案 iP网络广播求助对讲系统在智慧交通中起至关重要的作用。本系统具备公共广播系统一般用途的日常广播(播放背景音乐、话筒寻呼广播)和紧急广播。同时具有背景音乐广播、公共广播、紧急广播、语音求助全双工双向对讲等功能。在出现突发性交通事故或恶劣…

复现黄金票据

一、具体内容 黄金票据是一种在域环境中利用 Kerberos 协议漏洞的攻击方式。 在网络安全中复现黄金票据通常包括以下步骤&#xff1a; 1. 信息收集&#xff1a;获取目标域的相关信息&#xff0c;如域名、域控制器的 IP 地址等。 2. 生成黄金票据&#xff1a;使用特定工具或脚本…

CTF比赛中JWT漏洞的利用

前言 在最近的ctf比赛中&#xff0c;经常可以碰到一些jwt相关的题目&#xff0c;然后感觉思路挺有意思&#xff0c;拿出来分享一下&#xff0c;后边也总结一下ctf比较常见的集jwt相关题目解题思路 算法混淆漏洞 腾龙杯 web[这又是一个登录页面] 使用zkaq/zkaq登录之后&#…

在编程中使用中文到底该不该??

看到知乎上有个热门问题&#xff0c;为什么很多人反对中文在编程中的使用&#xff1f; 这个问题有几百万的浏览热度&#xff0c;其中排名第一的回答非常简洁&#xff0c;我深以为然&#xff1a; 在国内做开发&#xff0c;用中文写注释、写文档&#xff0c;是非常好的习惯&…

Lua环境下载与配置

这里介绍如何下载已经编译好的Lua环境&#xff0c;如何配置Lua环境。 如希望自己从源码编译Lua环境&#xff0c;请自行搜索资料。 第一步&#xff1a;下载编译好的lua环境 打开下面链接&#xff0c;然后根据指引下载。 The Programming Language Luahttps://www.lua.org/hom…

linux进程退出之exit与_exit

linux进程退出之exit与_exit _exitexit流程清理函数atexit()函数&#xff1a;on_exit()函数&#xff1a; _exit /* Terminate program execution with the low-order 8 bits of STATUS. */ /** status参数定义了进程的终止状态&#xff0c;父进程可以通过wait&#xff08;&am…

前端学习<四>JavaScript基础——01-编程语言和JavaScript简介

计算机语言 概念 计算机语言&#xff1a;人与计算机之间通信的语言。它是人与计算机之间传递信息的媒介&#xff0c;它通过特定的语法规则和语义约定&#xff0c;将人类可理解的指令转化为计算机可以执行的机器指令。 计算机程序&#xff1a;就是计算机所执行的一系列的指令…

【2024系统架构设计】案例分析- 5 Web应用

目录 一 基础知识 二 真题 一 基础知识 1 Web应用技术分类 大型网站系统架构的演化:高性能、高可用、可维护、应变、安全。 从架构来看:MVC,MVP,MVVM,REST,Webservice,微服务。

Pytorch for training1——read data/image

blog torch.utils.data.Dataset create dataset with class torch.utils.data.Dataset automaticly import torch from torch.utils.data import Datasetclass MyDataset(Dataset):def __init__(self, data):self.data datadef __getitem__(self, index):# 根据索引获取样本…

排序算法-归并排序

Leetcode链接&#xff1a;. - 力扣&#xff08;LeetCode&#xff09; 归并&#xff1a;将原始数组划分为若干个子数组&#xff0c;然后将这些子数组分别排序&#xff0c;最后再将已排序的子数组合并成一个有序的数组。是一种分治思想 思路&#xff1a; 1.分 2.治 3.怎么治 …

Codeforces TypeDB Forces 2023 C. Remove the Bracket【上下界DP】

C. Remove the Bracket 题意 给定一个长度为 n n n 的整数数组 a a a 和一个非负整数 s s s 要求 ∀ i ∈ [ 2 , n − 1 ] , 选定两个整数 x i , y i &#xff0c;满足 x i y i s 且 ( x i − s ) ( y i − s ) ≥ 0 \forall i \in [2,n - 1],选定两个整数 x_i, y_i&am…