跳到主要内容
版本:3.2.14.4

建立 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. 在遵循上述建议并完成测试后,可根据实际需求进行其他场景的基准测试。但在执行之前,请确保收集的性能基线测试结果与参考数据基本一致,并仔细阅读下方提供的优化建议,根据实际测试需求对配置进行必要的调整。

性能基线测试部署拓扑

ec2 deploy

性能基线测试结果

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

测试案例路由/消费者数量QPSP99 (MS)P95 (MS)
未启用任何插件1 条路由,0 个消费者24,129.220.0930.082
未启用任何插件100 条路由,0 个消费者23,652.910.0960.084
只启用 limit-count 限流限速插件1 条路由,0 个消费者20,495.100.1040.092
只启用 limit-count 限流限速插件100 条路由,0 个消费者20,462.310.1040.094
只启用 key-auth 身份认证插件1 条路由,1 个消费者21,019.040.1000.089
只启用 key-auth 身份认证插件100 条路由,100 个消费者20,444.810.1090.095
同时启用 key-auth 和 limit-count 插件1 条路由,1 个消费者18,940.390.1100.097
同时启用 key-auth 和 limit-count 插件100 条路由,100 个消费者18,193.880.1100.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