建立 API7 Gateway 性能测试报告

前置准备

为确保 API7 Gateway 性能评估的准确性，在进行基准测试之前，请遵循以下关键建议和步骤：

• 选择合适的节点配置：
  1. 使用单个 API7 Gateway 节点，并根据节点资源（CPU 核心数）合理配置 worker_processes 的数量，建议先配置 1 个 worker_processes 进行基线测试，确认结果无误后再进行多核心的性能测试。
  2. 避免使用多个较小 worker_processes 数配置的 API7 Gateway 节点。
• 逐步增加 worker_processes：
  1. 初始测试时，配置 1 个 worker_processes 以获取单核心的性能基线。
  2. 在确认单核心性能无误后，逐步增加 worker_processes 的数量，以评估多核心下的性能表现。
• 排除上游网络等干扰：
  1. 仅启用 mocking 插件获取 API7 Gateway 的性能测试结果，此插件将以指定的格式返回模拟数据，且请求不会转发到上游服务器；
• 确保上游服务器性能：
  1. 在测试过程中，密切监控 API7 Gateway 和上游服务器的性能表现，确保上游服务器不是性能瓶颈。
• 收集基线值：
  1. 在进行更多场景的测试之前，先收集基线值。配置 1 个 API7 Gateway 节点，启用 1 个 worker_processes。
  2. 消除网关延迟干扰。将上游服务器和 API7 Gateway 部署在同一台机器，并使用 Host 网络。
  3. 确保收集的基线值与我们提供的参考结果基本一致。
• 收集并分析测试结果：
  1. 收集多组测试结果，通过统计手段（如标准差）分析数据之间的差异，确保测试结果的稳定性和可靠性。
• 参考优化建议：
  1. 在遵循上述建议并完成测试后，可根据实际需求进行其他场景的基准测试。但在执行之前，请确保收集的性能基线测试结果与参考数据基本一致，并仔细阅读下方提供的优化建议，根据实际测试需求对配置进行必要的调整。

性能基线测试部署拓扑

性能基线测试结果

统计基线测试结果时，我们将 API7 Gateway（1 worker_processes）、NGINX 上游服务器和压测工具 wrk2 部署在同一台机器上，并使用本机网络进行通信。

测试案例	路由/消费者数量	QPS	P99 (MS)	P95 (MS)
未启用任何插件	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

遵循以上步骤和建议，你将能够更准确地评估 API7 Gateway 在不同场景下的性能表现，并为后续的优化和部署提供有力的数据支持。

优化 API7 Gateway 性能

检查最大打开文件数

检查当前系统总体最大打开文件数：

cat /proc/sys/fs/file-nr
3984 0 3255296

最后一个数字 3255296 是打开文件的最大数量。如果这个数字在你的机器上很小，你需要修改 /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 检查，如果是一个很小的值（默认为 1024），我们需要修改它增加为百万级，如：1024000。

临时修改：

ulimit -n 1024000

Linux 永久修改：

vim /etc/security/limits.conf

# 添加如下行
* hard nofile 1024000
* soft nofile 1024000

避免资源争夺

确保 wrk2、API7 Gateway、上游服务分别位于不同的机器上，并在同一本地网络上进行测试，降低网络延迟带来的开销。

如果这些资源都在 Kubernetes 集群中运行，请确保这三个系统的 Pod 调度在各自的节点上。避免它们之间产生资源争用（通常是 CPU 和网络）导致性能不佳。

上游服务器已达到极限

检查上游服务器是否达到极限，压测过程注意观测上游服务器的 CPU 和内存的使用情况来确定上游服务器是否已经达到了极限。如果增加 API7 Gateway 的 worker_processes 数之后的结果仍保持不变，那么上游服务器或者其他系统可能达到了瓶颈。

阻止访问日志 I/O

在进行性能测试时，我们应该尽量减少访问日志对性能的影响，尤其是高流量场景下的大量日志写入操作，我们可以禁用 access_log 减轻对磁盘 I/O 的压力。

云供应商的性能问题

避免使用云服务器提供的可突发实例，这种实例的可用 CPU 是可变的，这会对测试数据带来不必要的影响。

信息

不同云供应商提供的实例类型中，vCPU（虚拟CPU）和物理 CPU 之间的对应关系并不总是 1:1 的。部分实例的 vCPU 是超线程的，这意味着实际的物理 CPU 核心数可能仅为 vCPU 数量的一半。为了准确了解特定实例类型的 vCPU 与物理 CPU 对应关系，建议查阅云供应商官方公布的文档。如 AWS 实例信息。

API7 Gateway 中的内部错误

将 API7 Gateway 错误日志调整成 error 级别，确保错误日志中不存在内部错误后再开始进行性能测试。

使用 c1000k 检查并发连接

安装 c1000k 检查测试环境是否能够满足 100w 个并发连接的要求。

# 启动服务器，监听 7000
. /server 7000

# 运行客户端，模拟压力测试
. /client 127.0.0.1 7000

API7 Gateway 配置示例

# config.yaml
nginx_config:
  error_log_level: error
  worker_processes: auto

  http:
    enable_access_log: false