性能基准
本页介绍 API7 网关已发布的基准测试结果及其测试方法,帮助你理解测试数据并在自己的环境中复现。所有测试资产(ADC 配置、wrk2 脚本和部署清单)均可在 api7-gateway-performance-benchmark 仓库中获取。
方法论
该基准测试使用一组固定的变量,以便跨测试运行和环境的结果具有可比性:
- 单个网关节点:一个 API7 网关数据面实例,其中
worker_processes配置为与主机的 vCPU 数量匹配。要构建干净的单核基准,请从worker_processes: 1开始,并在确认单核数字后进行扩展。 - 排除上游对性能上限的影响:仅启用
mocking插件来测量 API7 网关的原始请求处理上限。mocking插件直接返回预设响应,不会将请求转发到上游。因此,该结果不能与实际代理场景的吞吐量直接比较。 - 使用真实上游测试代理场景:除
mocking场景外,其他测试均使用运行nginx/1.25.4的真实 NGINX 上游,并配置access_log off和 200 字节静态响应,避免上游自身成为瓶颈。 - 样本大小:每个测试用例运行 5 次,每次运行 2 分钟,报告的结果是 5 次运行的平均值。
- 测试场景:5 个插件组合 × 2 种路由/消费者规模 = 10 个测试用例:
- 仅
mocking(基线上限) - 无插件
- 仅
limit-count - 仅
key-auth key-auth和limit-count
- 仅
每个插件场景分别使用两种规模运行,以衡量资源数量对路由匹配和插件执行的影响:一种包含 1 个路由和 1 个消费者,另一种包含 100 个路由和 100 个消费者。
已发布结果:AWS EKS
这些结果来自 AWS EKS 环境:使用运行 Amazon Linux 2(AL2_x86_64)的 c5.4xlarge EC2 实例(16 个 vCPU、32 GB RAM)和 Kubernetes 1.29。API7 网关、NGINX 上游和 wrk2 分别运行在同一 VPC 的独立节点上,以避免资源争用。
转发到上游列用于区分仅使用 mocking 插件的理论上限测试(API7 网关直接返回预设响应,请求不会离开网关)和实际代理场景。仅使用 mocking 的结果表示网关请求处理链路的理论上限,不能与受后端和网络影响的实际吞吐量直接比较。估算生产环境容量时,请使用“转发到上游”为 True(Forward to Upstream: True)的数据。
- AWS EKS(c5.4xlarge)
- 单主机基线(1 个 worker)
| 测试场景 | 路由/消费者 | 转发到上游 | QPS | P99(毫秒) | P95(毫秒) |
|---|---|---|---|---|---|
仅 mocking | 1 个路由,0 个消费者 | False | 310,392.07 | 1.16 | 1.08 |
| 无插件 | 1 个路由,0 个消费者 | True | 167,019.37 | 2.30 | 2.16 |
| 无插件 | 100 个路由,0 个消费者 | True | 162,753.17 | 2.31 | 2.16 |
仅 limit-count | 1 个路由,0 个消费者 | True | 145,370.10 | 2.43 | 2.24 |
仅 limit-count | 100 个路由,0 个消费者 | True | 143,108.40 | 2.45 | 2.25 |
仅 key-auth | 1 个路由,1 个消费者 | True | 147,869.49 | 2.41 | 2.22 |
仅 key-auth | 100 个路由,100 个消费者 | True | 145,070.93 | 2.43 | 2.25 |
key-auth + limit-count | 1 个路由,1 个消费者 | True | 136,725.47 | 2.43 | 2.26 |
key-auth + limit-count | 100 个路由,100 个消费者 | True | 133,782.95 | 2.48 | 2.30 |
该基线使用主机网络,在同一台计算机上运行 API7 网关(worker_processes: 1)、NGINX 上游和 wrk2,用于在不受网络延迟影响的情况下测量单核吞吐量。
| 测试场景 | 路由/消费者 | QPS | P99(毫秒) | P95(毫秒) |
|---|---|---|---|---|
| 无插件 | 1 个路由,0 个消费者 | 24,129.22 | 0.093 | 0.082 |
| 无插件 | 100 个路由,0 个消费者 | 23,652.91 | 0.096 | 0.084 |
仅 limit-count | 1 个路由,0 个消费者 | 20,495.10 | 0.104 | 0.092 |
仅 limit-count | 100 个路由,0 个消费者 | 20,462.31 | 0.104 | 0.094 |
仅 key-auth | 1 个路由,1 个消费者 | 21,019.04 | 0.100 | 0.089 |
仅 key-auth | 100 个路由,100 个消费者 | 20,444.81 | 0.109 | 0.095 |
key-auth + limit-count | 1 个路由,1 个消费者 | 18,940.39 | 0.110 | 0.097 |
key-auth + limit-count | 100 个路由,100 个消费者 | 18,193.88 | 0.110 | 0.098 |
单主机与多节点环境的结果不能直接比较:多节点 AWS EKS 环境可使用 16 个 vCPU,而单主机基准将 API7 网关限制为单个 worker_process。扩容前,请先使用单主机数据确认自己的单核结果与参考值大致一致。
运行你自己的基准测试
要重现这些数字或测量你自己的工作负载,请遵循与已发布结果相同的方法并应用下面的优化指南。
开始之前
- 选择适当数量的网关节点。 每次测试只使用一 个 API7 网关节点,并将
worker_processes配置为与主机 vCPU 数量一致。不要并行运行多个worker_processes较小的 API7 网关实例,否则测试结果难以准确解释。 - 首先构建单核基线。 设置
worker_processes: 1并针对同一主机上的本地 NGINX 上游运行“无插件”场景。在横向扩展之前,你的结果应该与上面的单主机基准表大致相同。 - 排除上游对性能上限的影响。 仅启用
mocking插件,以单独测量 API7 网关自身的处理开销。 - 观察上游。 在每次实际测试期间,监视 NGINX 上游的 CPU、内存和事件循环利用率。如果上游饱和,则数字反映上游的限制,而不是 API7 网关的限制。
- 运行多个样本并应用统计数据。 每个测试用例应至少运行 5 次。报告平均值和标准差,以便将噪声与信号分开。
有关创建集群、标记节点、安装 Helm、部署 NGINX 上游和部署 wrk2 的完整 AWS EKS 操作流程,请参见在 AWS EKS 上运行基准。
优化建议
提高打开文件的最大数量
查看系统当前最大打开文件描述符数:
cat /proc/sys/fs/file-nr
最后一个数字是系统级上限。如果该值过小,请在 /etc/sysctl.conf 中提高:
fs.file-max = 1020000
net.ipv4.ip_conntrack_max = 1020000
net.ipv4.netfilter.ip_conntrack_max = 1020000
重新加载:
sudo sysctl -p /etc/sysctl.conf
提高每个进程的 ulimit
每个传入连接都会消耗一个文件描述符。将 ulimit -n 提高到七位数的值,以便网关可以接受基准测试生成的连接量。
临时(仅限当前 shell):
ulimit -n 1024000
永久生效(编辑 /etc/security/limits.conf):
* hard nofile 1024000
* soft nofile 1024000