性能基准

本页面记录了 API7 Gateway 已发布的基准测试结果及其背后的方法，因此你既可以理解这些数字，也可以在自己的环境中重现它们。所有测试资产（ADC 配置、wrk2 脚本和部署清单）均可在 api7-gateway-performance-benchmark 存储库中获取。

方法论

该基准测试使用一组固定的变量，以便跨测试运行和环境的结果具有可比性：

• 单个网关节点：一个 API7 网关数据面实例，其中 worker_processes 配置为与主机的 vCPU 数量匹配。要构建干净的单核基准，请从 worker_processes: 1 开始，并在确认单核数字后进行扩展。
• 排除上游对上限数量的干扰：仅启用 mocking插件来测量 API7 网关的原始请求处理上限。mocking插件返回预设响应，而不转发到上游。这个数字与现实世界的吞吐量无法比较。
• 转发到上游的真实场景：每个其他测试行都使用运行 nginx/1.25.4 的真实 NGINX 上游，配置有 access_log off 和静态 200 字节响应，以便上游本身从来都不是瓶颈。
• 样本大小：每个测试用例运行 5 次，每次运行 2 分钟，报告的结果是 5 次运行的平均值。
• 测试场景：5 个插件组合 × 2路由/消费者量表 = 10 个测试用例： 1.仅mocking（基线上限） 2.无插件 3.仅limit-count 4.仅key-auth 5. key-auth 和 limit-count

每个插件场景均使用 (a) 1 个路由/ 1 个消费者和 (b) 100 个路由/ 100 个消费者运行，以衡量资源计数对匹配和插件执行。

已发布结果 — AWS EKS

这些结果是在 AWS EKS 环境中使用运行 Amazon Linux 2 (AL2_x86_64) 的 EC2 实例（16 个 vCPU，32 GB RAM）获得的。Kubernetes 1.29。API7 网关、NGINX 上游和 wrk2 各自在同一 VPC 中的单独节点上运行，以避免资源争用。

备注

转发到上游 列将仅模拟上限（其中 API7 网关返回预设响应并且没有请求离开网关）与实际代理场景区分开来。仅模拟行测量网关请求处理管道的理论上限；它与现实世界的吞吐量不可比，其中后端和网络成为额外的因素。调整生产尺寸时，请使用带有 Forward to Upstream: True 的行。

AWS EKS (c5.4xlarge)

测试场景	路由/消费者	转发到上游	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

Single-host baseline (1 worker)

此基线是通过使用主机网络在同一台计算机上运行的 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 次。报告平均值和标准差，以便将噪声与信号分开。

有关完整的 AWS EKS 演练 — 集群创建、节点标记、Helm 安装、NGINX 上游部署和 wrk2 部署 — 请参阅在 AWS EKS 上运行基准测试。

优化建议

提高打开文件的最大数量

查看系统当前最大打开文件描述符数：

cat /proc/sys/fs/file-nr

最后一个数字是系统范围的最大值。如果太小，则在/etc/sysctl.conf中提高：

/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）：

/etc/security/limits.conf

* hard nofile 1024000
* soft nofile 1024000

禁用访问日志

每个请求的访问日志都会写入磁盘，这可以在大容量测试期间限制 QPS 的 I/O 速度。禁用它们进行基准测试：

config.yaml

nginx_config:
  error_log_level: error
  worker_processes: auto
  http:
    enable_access_log: false

将错误日志级别设置为 error 还会减少运行期间的日志 I/O。

避免资源争用

将 wrk2、API7 网关和上游服务放在同一本地网络中的不同计算机上。在 Kubernetes 中运行时，使用 nodeSelector （或污点和容忍）使三个 pod 降落在三个不同的节点上，否则 CPU 和网络争用会扭曲结果。

避免突发云实例

请勿对突发云实例系列（例如 AWS t3/t4g）进行基准测试。 Burstable 实例具有基于信用的 CPU 模型，可生成不可重复的结果。请改用 c5.4xlarge 等固定性能系列。

另请注意，云提供商的 vCPU 与物理核心并不总是 1:1 — 许多使用超线程，这意味着实际物理核心数量可能是 vCPU 数量的一半。要获得最准确的大小调整，请参阅云提供商的实例文档（有关 AWS，请参阅 AWS 实例 CPU 选项）。

观察网关中的内部错误

在每次基准测试运行之前，跟踪 API7 网关错误日志并验证其是否干净。内部错误循环（例如，触发重试的上游DNS 故障）将默默地降低测量的吞吐量。将网关日志级别设置为 error 并在测量之前修复日志报告的所有内容。

使用 c1000k 验证连接容量

如果你的目标超过数十万个并发连接，请验证主机内核和文件描述符限制是否确实可以维持它们。 c1000k工具是一个小探针，可以模拟一百万个并发连接：

# 在服务端节点上
./server 7000

# 在客户端节点上
./client <server-ip> 7000

后续步骤

• 在 AWS EKS 上运行基准测试 — 用于重现已发布的 AWS EKS 结果的完整演练。
• 配置数据面 — 根据你的工作负载调整数据面设置。
• 缩放数据面 — 在 Kubernetes 中水平和垂直缩放。
• 数据面的高可用性 — 多副本弹性模式。