测试目的
通过控制变量法，使用压力测试工具直接对后端服务、网关代理请求到后端服务的场景进行压测，对比分析各网关性能差异。
测试方案
1）软件信息
2）被测接口
基本信息
👉请求地址：172.18.65.54:8980/ping
👉响应数据：静态HTML，减少可能造成压测性能影响的因素。
响应头部
响应体
3）网络拓扑结构
压测程序、网关程序、后端服务程序应部署在不同的服务器，避免同一服务器多个程序发生资源争抢。服务器均部署在同一个局域网中，服务器间使用内网IP进行通信，避免外部网络波动影响压测结果，具体拓扑结构图如下。
网关代理压测
4）硬件资源
5）性能调优
修改三台服务机器最大 TCP 连接数，提高服务器最高支持的并发数
- 编辑
/etc/sysctl.conf
- 修改
net.ipv4.tcp_max_syn_backlog配置为65535
- 让配置生效
开始测试
在测试过程中，应遵循控制变量原则，避免程序资源争抢，当压测任一网关时，其余网关程序应当停止运行。
另外，我们需要关闭网关多余的 I/O 操作，比如请求日志打印，否则会造成数据的误差。为了尽可能模拟多个用户同时并发，避免触发连接 keep-alive，保证每次请求的连接都是新创建的，因此，在进行发送请求时，需要携带请求头 Connection:Close。
本文仅记录 100 并发、200 并发下，连续请求 1 分钟时各网关产品的表现情况。
Apinto
100并发下执行1分钟
执行命令
./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8099/ping结果展示
Running 1m test @ http://172.18.65.76:8099/ping
8 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.57ms 2.59ms 202.08ms 91.26%
Req/Sec 5.25k 298.96 10.19k 86.09%
Latency Distribution
50% 2.02ms
75% 3.30ms
90% 4.91ms
99% 9.96ms
2507816 requests in 1.00m, 4.76GB read
Requests/sec: 41728.11
Transfer/sec: 81.02MB200并发下执行1分钟
执行命令
./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8099/ping结果展示
Running 1m test @ http://172.18.65.76:8099/ping
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 5.46ms 4.70ms 223.80ms 77.54%
Req/Sec 5.24k 334.33 13.98k 83.99%
Latency Distribution
50% 4.40ms
75% 7.50ms
90% 11.48ms
99% 20.98ms
2502384 requests in 1.00m, 4.74GB read
Requests/sec: 41637.53
Transfer/sec: 80.85MBNginx
100并发下执行1分钟
执行命令
./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8999/ping结果展示
Running 1m test @ http://172.18.65.76:8999/ping
8 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.22ms 17.00ms 212.10ms 98.05%
Req/Sec 3.07k 664.30 6.28k 72.81%
Latency Distribution
50% 1.75ms
75% 2.46ms
90% 3.43ms
99% 109.18ms
1465380 requests in 1.00m, 2.81GB read
Requests/sec: 24382.41
Transfer/sec: 47.81MB200并发下执行1分钟
执行命令
./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8999/ping结果展示
Running 1m test @ http://172.18.65.76:8999/ping
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 6.68ms 23.83ms 1.00s 96.62%
Req/Sec 3.09k 771.87 7.15k 71.45%
Latency Distribution
50% 2.29ms
75% 3.48ms
90% 5.32ms
99% 155.15ms
1478385 requests in 1.00m, 2.83GB read
Requests/sec: 24598.89
Transfer/sec: 48.23MBKong
100并发下执行1分钟
执行命令
./wrk -t8 -c100 -d60s -H "Connection: Close" --latency http://172.18.65.76:8000/ping结果展示
Running 1m test @ http://172.18.65.76:8000/ping
8 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 7.91ms 15.80ms 361.41ms 94.35%
Req/Sec 2.04k 301.81 2.76k 72.99%
Latency Distribution
50% 3.71ms
75% 9.81ms
90% 18.00ms
99% 46.10ms
972890 requests in 1.00m, 1.96GB read
Requests/sec: 16213.08
Transfer/sec: 33.41MB200并发下执行1分钟
执行命令
./wrk -t8 -c200 -d60s -H "Connection: Close" --latency http://172.18.65.76:8000/ping结果展示
Running 1m test @ http://172.18.65.76:8000/ping
8 threads and 200 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 17.63ms 37.04ms 581.50ms 92.13%
Req/Sec 2.05k 618.45 3.18k 82.57%
Latency Distribution
50% 6.43ms
75% 15.28ms
90% 41.98ms
99% 131.93ms
966126 requests in 1.00m, 1.94GB read
Requests/sec: 16099.00
Transfer/sec: 33.18MB测试图表展示
QPS
横轴为并发数，纵轴为当前并发量时，各网关每秒能够处理的请求数。
错误数
横轴为并发数，纵轴为当前并发量时，各网关返回的非200、300状态码的错误响应数量。
请求耗时
横轴为并发数，纵轴为当前并发量时的请求耗时情况，单位：ms。
总结
Apinto 网关性能表现优异。相同环境下，Apinto 拥有比 Nginx 高 65% 左右的吞吐量表现，拥有极强的性能表现和优异的稳定性，99% 的请求都可以在 100ms 内转发完成，代理损耗极低。
Nginx 和 Kong 在 1000 并发时，开始出现了错误请求，相比之下，Apinto 即使在 1000 并发时，依然表现良好，稳定工作。
