建立性能基准

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

先决条件

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

性能基准测试部署拓扑

性能基准测试结果

在收集基准测试结果时，API7 网关（带有 1 个 worker_process）、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 网关在不同场景下的性能，为后续优化和部署提供有价值的数据支持。

优化 API7 网关性能

检查最大打开文件数

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

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

最后一个数字 3255296 代表最大打开文件数。如果你机器上的这个数字太小，你需要修改 /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 进行检查，如果它是一个较小的值（默认为 1024），则应将其修改为百万级别的数字，例如 1024000。

要临时修改它：

ulimit -n 1024000

要永久修改它：

vim /etc/security/limits.conf

# Add the following lines
* hard nofile 1024000
* soft nofile 1024000

避免资源争用

确保 wrk2、API7 网关和上游服务安装在不同的机器上，并在同一个局域网内进行测试，以减少网络延迟造成的开销。

如果这些资源在单个 Kubernetes 集群上运行，请确保这三个服务的 Pod 调度在不同的节点上，以避免资源争用（例如在 CPU 和网络方面），这可能会导致性能下降。

上游服务器达到极限

检查上游服务器是否达到其极限。在压力测试期间，监控上游服务器的 CPU 和内存使用情况，以确定它是否已达到其最大容量。如果增加 API7 网关中的 worker_processes 数量没有带来任何改善，则可能是上游服务器或其他系统已达到瓶颈。

禁用访问日志的 I/O

在性能基准测试期间，重要的是要最大限度地减少访问日志对性能的影响，尤其是在涉及大量日志写入操作的高流量场景中。禁用 access_log 可以减轻磁盘 I/O 的压力。

云提供商性能问题

避免使用云服务器提供的突发性能实例（burstable instances）。此类实例的可用 CPU 是可变的，这会不必要地影响测试数据。

信息

不同的云提供商在其实例类型中提供的 vCPU（虚拟 CPU）和物理 CPU 之间的映射并不总是 1:1。某些实例使用超线程技术，这意味着物理 CPU 核心的实际数量可能只有 vCPU 数量的一半。

为了准确了解特定实例类型的 vCPU 到物理 CPU 映射，建议查阅云提供商发布的官方文档。例如，请参阅 AWS 实例信息。

API7 网关内部错误

在开始性能基准测试之前，必须将 API7 网关中的日志严重级别调整为 error，并确保错误日志中没有内部错误。

使用 c1000k 检查并发连接

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

# Start the server, listening on port 7000
./server 7000

# Run the client to simulate a stress test
./client 127.0.0.1 7000

API7 网关配置示例

config.yaml

nginx_config:
  error_log_level: error
  worker_processes: auto

  http:
    enable_access_log: false