拆分登录请求后线程数降至200的异常问题求助

问题背景 #

登录用例包含10个请求URL：前5个为**认证（Authentication）请求，后5个为授权（Authorization）**请求。为单独获取认证环节响应时间，将登录流程拆分为两部分后出现异常：

• 未拆分时，单请求模式线程数可达250
• 拆分后，线程数仅能达到200
• 此前拆分时线程数可正常到250，脚本无任何修改

排查方向 #

1. 资源竞争与瓶颈 #

• 检查拆分后认证环节是否触发了资源锁定逻辑（如会话存储、数据库连接池），未拆分时授权环节的延迟可能掩盖了认证的资源消耗，拆分后认证请求并发集中触发，暴露了资源瓶颈
• 监控服务器端CPU、内存、网络带宽，对比拆分前后的资源使用率差异，重点核查认证服务的连接数上限（如Tomcat的maxConnections、Nginx的worker_connections）

2. 会话与状态管理 #

• 确认拆分后认证请求是否正确复用或清理会话：若认证后未及时释放会话资源，可能导致会话池耗尽，限制并发线程数
• 检查是否存在会话粘连（如负载均衡器的粘性会话），拆分后认证请求集中到特定服务器，引发单节点过载

3. 脚本执行逻辑 #

• 排查是否存在隐式依赖：未拆分时授权环节会自动携带认证后的Cookie/Token，拆分后若遗漏认证状态传递（如未正确保存Token到全局变量），会导致请求失败、线程阻塞
• 核查脚本超时设置：拆分后认证请求的超时时间是否过短，导致请求提前失败，无法维持高并发线程数

4. 测试工具配置 #

• 检查测试工具（如JMeter）的线程组配置：拆分后是否误改线程数上限、Ramp-Up时间，或新增了不必要的延迟逻辑
• 查看工具连接池设置：如JMeter的httpclient4.maxConnections，确认拆分后认证请求的并发连接数是否超过工具连接池上限

5. 服务端限流策略 #

• 确认服务端是否新增认证接口专属限流规则（如QPS限制、IP级限流），此前拆分时未触发，现在因请求模式变化触发了限流
• 检查认证接口错误日志，是否存在429 Too Many Requests、503 Service Unavailable等限流或过载报错

内容的提问来源于stack exchange，提问作者Prashanth Kumar J