API 网关并发连接数测试：别让数字骗了你

API 网关并发连接数测试：别让数字骗了你

很多团队在选型或压测时，习惯性地盯着“最大并发连接数”这个指标，觉得数字越大越好。但实际生产环境中，网关在高并发下出现的超时、丢包、内存暴涨，往往不是因为连接数不够，而是因为测试方法本身就有漏洞。把并发连接数当成一个孤立的静态数值来看，很容易踩坑。

测试前的认知准备

并发连接数测试本质上是验证网关在特定资源限制下，同时处理多个连接请求的能力。但这里有一个关键误区：并发连接数并不等于每秒请求数。一个连接上可以传输多个请求，而一个请求也可能复用多个连接。很多测试方案只关注“建立了多少TCP连接”，却忽略了连接上承载的实际业务流量。正确的做法是先定义清楚业务场景——是长连接轮询、短连接突发，还是混合流量。不同场景下，网关的瓶颈点完全不同，内存占用、CPU上下文切换、文件描述符上限，都会影响最终结果。

搭建贴近实际的测试环境

测试环境不能图省事。常见的问题是本地单机压测，网关和客户端跑在同一台机器上，结果把系统资源争抢也算进了网关的性能损耗。更合理的做法是使用独立的压测节点，网络链路模拟真实延迟，甚至引入丢包和抖动。工具方面，wrk、locust、vegeta都能做基础压测，但要注意它们默认使用短连接或长连接的方式不同，需要手动调整参数。比如用wrk时，-c参数控制并发连接数，-d控制持续时间，但如果不设置连接复用，实际产生的请求量会远低于预期。测试前先跑一个基准值，确认压测工具本身不会成为瓶颈。

关键指标不止一个

只看并发连接数容易出问题。真正需要关注的是三个维度的数据：连接建立成功率、平均响应时间、错误率。当并发连接数逐渐增加时，响应时间会经历三个阶段——平稳期、缓慢上升期、急剧恶化期。网关的“最大并发连接数”应该定义在急剧恶化期到来之前的那个拐点。此外，还要观察网关的内存和CPU变化。如果连接数上去后内存持续增长不回落，说明可能存在连接泄漏；如果CPU飙高但吞吐量没变，可能是协议解析或线程调度出了问题。这些数据配合起来，才能判断网关是否真的扛得住。

不同协议下的差异不可忽视

HTTP/1.1、HTTP/2、WebSocket、gRPC，每种协议对并发连接的处理逻辑完全不同。HTTP/1.1依赖多个连接来提升并发，而HTTP/2可以在一个连接上多路复用，对网关来说，连接数少但帧处理压力大。WebSocket则是长连接保活，网关需要维护大量状态信息。测试时如果只压HTTP/1.1，得出的结论不能直接套用到WebSocket场景。更隐蔽的问题是TLS握手——很多测试忽略了HTTPS，而TLS握手本身非常消耗CPU，实际生产环境中，并发连接数的瓶颈往往卡在SSL/TLS加解密上。如果测试方案不开启TLS，结果会虚高一大截。

常见陷阱和避坑方法

很多团队在测试时喜欢用“并发连接数达到X万”作为宣传点，但实际生产环境中的连接行为远不如压测脚本规律。比如客户端频繁重连、慢启动、半开连接，这些都会让网关的实际负载比压测数据大得多。一个常见陷阱是忽略连接超时设置。如果压测脚本里的超时时间设得特别长，网关会一直维持着慢速连接，导致资源被无效占用。正确的做法是设置合理的超时阈值，并在测试中模拟部分慢客户端。另外，测试结束后要检查网关是否有大量TIME_WAIT状态的连接，这往往说明连接关闭逻辑有问题。

从测试结果反推配置优化

测试不是为了得到一个数字，而是为了指导生产配置。如果发现并发连接数接近上限时CPU先扛不住，可以考虑升级硬件或调整线程模型；如果内存先爆，可能需要限制单连接缓冲区大小或启用连接池复用。一些网关产品支持动态调整最大连接数，但前提是底层操作系统参数也要同步修改，比如Linux的fs.file-max和net.ipv4.ip_local_port_range。测试报告里应该包含这些调优建议，而不是只给一个结论。对于企业官网的知识栏目来说，把测试过程拆解成可复用的方法论，比单纯罗列几个数字更有价值。