4. Kong性能基准测试：使用wrk、ab、hey等工具对Kong进行基准压测，理解吞吐量与延迟基线
性能基准测试是API网关调优的起点。在调整任何参数或插件之前，必须建立当前环境下的吞吐量（RPS）与延迟（Latency）基线。本章将使用业界主流的压测工具——wrk、ab（Apache Bench）和hey，对Kong进行基准压测，并解读关键指标。
4.1 压测工具对比与选型
不同工具在并发模型、统计输出和资源开销上存在差异。下表总结了三种工具的适用场景与核心参数：
| 工具 | 并发模型 | 核心参数示例 | 优势 | 局限 |
|---|---|---|---|---|
| wrk | 多线程 + 事件循环（基于Redis的ae） | -t2 -c100 -d30s |
高并发下CPU开销低；支持Lua脚本定制请求 | 仅支持HTTP/1.1；无原生分布式支持 |
| ab | 单进程 + 多线程（阻塞式） | -n 100000 -c 100 |
安装简单；输出包含连接时间分解 | 高并发下性能瓶颈明显；不支持HTTP/2 |
| hey | Go goroutine 并发 | -n 100000 -c 100 -m GET |
支持HTTP/2；输出延迟百分位图 | 单机压测；大并发时内存占用较高 |
选型建议： 日常基线测试推荐使用
wrk，其事件驱动模型能更真实地模拟高并发场景。若需要HTTP/2支持或详细的延迟分布图，则选择 hey。避免使用 ab 进行超过500并发的大规模压测。
4.2 基准测试环境与前置条件
为确保测试结果可复现，必须固定以下环境变量：
- Kong节点规格： 记录CPU核数、内存大小、内核版本（如
uname -r）。 - 数据库类型： PostgreSQL 或 Cassandra，以及连接池大小。
- 压测机与Kong的网络拓扑： 同机房内网（延迟 < 1ms）或跨机房。
- Kong配置基线： 关闭所有插件（仅保留
rate-limiting等必要插件），设置nginx_worker_processes = auto。
避坑： 压测机自身资源必须充足。若压测机CPU先达到100%，则瓶颈在压测端而非Kong。建议压测机CPU核心数不低于Kong节点的2倍。
4.3 使用wrk进行吞吐量与延迟基线测试
以下命令对Kong代理端口（默认8000）进行30秒压测，使用2个线程、100个并发连接：
wrk -t2 -c100 -d30s --latency http://kong-gateway:8000/api/v1/test典型输出解读：
Running 30s test @ http://kong-gateway:8000/api/v1/test
2 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 45.23ms 12.87ms 198.00ms 72.50%
Req/Sec 1.12k 150.23 1.45k 68.00%
Latency Distribution
50% 42.00ms
75% 52.00ms
90% 65.00ms
99% 120.00ms
67890 requests in 30.00s, 8.15MB read
Requests/sec: 2263.00
Transfer/sec: 278.00KB关键指标：
- Requests/sec (RPS): 2263 —— 当前配置下的吞吐量基线。
- Latency Avg: 45.23ms —— 平均延迟。
- P99 Latency: 120ms —— 99%请求的延迟上限，反映尾部延迟。
4.4 使用hey测试HTTP/2与延迟分布
若Kong开启了HTTP/2监听（默认端口8443），使用 hey 进行压测：
hey -n 100000 -c 100 -m GET -h2 http://kong-gateway:8443/api/v1/testhey 的输出包含ASCII延迟分布图，便于直观识别延迟集中区间：
Latency distribution:
10% in 38.12ms
25% in 41.50ms
50% in 45.00ms
75% in 52.30ms
90% in 68.10ms
95% in 85.40ms
99% in 130.20ms
对比要点： HTTP/2的多路复用通常会降低P50延迟，但可能增加P99延迟（由于头部压缩和流优先级调度）。务必与HTTP/1.1基线对比。
4.5 吞吐量与延迟基线关系图
下图展示了在固定并发下，吞吐量（RPS）与平均延迟之间的典型关系曲线，以及Kong的“拐点”区域：
4.6 多场景基线对比清单
建议至少完成以下4个场景的基线测试，并记录到统一的对比表中：
| 场景编号 | 测试描述 | 并发数 | 持续时间 | 预期RPS | 预期P99延迟 |
|---|---|---|---|---|---|
| S1 | 直连上游（绕过Kong） | 100 | 30s | ~5000 | < 20ms |
| S2 | Kong空路由（无插件） | 100 | 30s | ~2500 | < 50ms |
| S3 | Kong + 基础插件（限流+日志） | 100 | 30s | ~1800 | < 80ms |
| S4 | Kong + 认证插件（JWT/Key-Auth） | 100 | 30s | ~1200 | < 120ms |
基线价值： 通过S1与S2的差值，可以计算出Kong本身的代理开销（通常为2-5ms）。S3与S4的下降幅度则反映了插件对性能的影响权重，为后续调优提供量化依据。
4.7 压测结果的可信度检查
在记录基线之前，必须验证压测结果的有效性：
- 检查错误率： 所有工具输出的非2xx/3xx响应占比应 < 0.1%。若错误率过高，先排查路由或上游配置。
- 检查标准差：
Req/Sec Stdev不应超过平均值的30%。过大说明Kong节点存在抖动（如GC暂停、DB连接池争用）。 - 检查压测机资源： 压测期间压测机CPU使用率应 < 80%，否则需增加线程数或减少并发。
常见陷阱： 不要仅看平均值。P99延迟和最大延迟更能反映真实用户体验。若P99 > 3×P50，说明存在明显的长尾延迟问题，需要进一步诊断。