如何通过参数计算预期TPS及提升性能测试实际TPS

计算预期TPS通常分两种场景：

• 按业务需求测算：预期TPS = 峰值时段总请求数 / 峰值时段总秒数，比如业务峰值1小时要支撑1080万次请求，对应预期TPS就是10800000 / 3600 = 3000，也就是你提到的预期值。
• 按压测配置测算：你设置的吞吐量180000为分钟级阈值的话，预期TPS = 分钟吞吐量 / 60，180000/60=3000，和业务测算结果一致。
  如果要通过线程数倒推预期可达TPS，公式为：预期TPS = (1000ms / 单请求平均响应时间(ms)) * 有效并发线程数，可以提前用少量线程压测拿到平均响应时间，再计算需要的总线程数。

你当前实测2750和目标3000差距不大，可以按以下顺序排查优化：

• 先排除压测端本身瓶颈：检查压测工具（默认JMeter）所在机器的CPU、内存、出站带宽占用率，如果任意指标超过85%，说明压测机本身发不出足够请求，可尝试调大JMeter堆内存（修改启动配置中的-Xmx参数到4G及以上）、改用命令行模式压测、禁用所有非必要监听器，单台压测机不够就扩展分布式压测节点。
• 调整并发线程数：按前面的公式倒推，如果你当前接口平均响应时间在14-15ms左右，40线程的TPS上限就是2700-2800，刚好匹配你当前的实测值，只需要把线程数加到45-50就能触达3000的目标。另外检查所有定时器配置，确认没有误加思考时间，shaping timer的TPS阈值单位要和预期单位匹配，避免换算错误。
• 排查服务端性能瓶颈：如果调大线程数后TPS不再上涨，就检查被压服务的CPU、内存、GC频率、数据库/缓存耗时、网络/磁盘IO指标，哪项资源达到瓶颈就对应优化：比如SQL慢就加索引、服务CPU占用高就优化业务逻辑、单机性能到顶就扩容服务实例。

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