JMeter的TPS无法代表实际每秒处理请求数时应参考哪个参数？

一、正确的测算指标 #

测算服务每秒处理请求数的核心指标是JMeter报告中的吞吐量（Throughput），官方统计逻辑为总请求数 / 测试总时长（从第一个请求发起时刻到最后一个请求结束时刻的时间差），结果即为服务每秒处理的请求数，若你使用事务控制器封装多个请求为一个业务事务，该指标对应每秒事务数（TPS）。

你之前的认知存在两处偏差：

• 单实例下单请求elapsed time为1s对应TPS为1的结论，仅适用于单线程串行发请求的理想场景，和真实并发场景下的统计逻辑无关
• 服务扩容后的理论TPS上限，仅代表服务端的理论处理能力，实际值会受施压端能力、网络链路、中间件瓶颈等多因素限制

二、扩容后TPS未达理论值的排查方向 #

• 确认JMeter施压配置是否足够：要达到3实例单请求1s对应的3TPS理论值，至少需要配置3个及以上并发线程，同时设置足够长的施压时长，排除请求爬升期的统计偏差
• 排除流量转发异常：检查负载均衡配置是否正常，3个实例是否均匀承接流量，是否存在请求全部落到单实例的情况
• 排查服务下游瓶颈：确认服务依赖的数据库、缓存、第三方接口等下游组件是否存在性能瓶颈，是否有连接池上限、全局锁等配置限制总并发处理能力
• 排除JMeter本身瓶颈：测试过程中监控JMeter施压端的CPU、内存、网络占用，确认施压端本身没有性能瓶颈，同时检查采样结果是否存在报错，报错会拉低最终吞吐量统计值

内容的提问来源于stack exchange，提问作者Lau