如何解读JMeter生成的TPS及相关性能图表？附测试参数

你的测试场景：GET请求"A"，1000线程，100秒ramp-up（每秒启动10个线程），循环次数1次。下面逐个拆解三个图表的含义：

一、Active Threads Over Time（随时间变化的活跃线程数） #

横轴是测试时间，纵轴是当前正在运行的线程数量。

• 正常趋势：测试开始后的前100秒，线程数会从0稳步涨到1000（每秒启动10个）；100秒后，线程陆续完成单次请求，活跃线程数会逐步降到0。
• 异常信号：如果100秒后线程数长时间居高不下，说明请求响应太慢，线程卡在等待结果；如果增长阶段不是平稳的线性上升，可能是你的JMeter机器资源不够，没法按预期启动线程。

二、Transactions per Second（TPS，每秒事务数） #

横轴是时间，纵轴是每秒完成的请求（事务）数量。

• 正常趋势：前100秒，随着活跃线程数增加，TPS会逐步上升，在100秒左右达到峰值（此时1000个线程都在发请求）；之后线程陆续结束，TPS慢慢降到0。峰值高低看服务器处理能力，比如服务器平均响应1秒的话，峰值TPS大概能到1000。
• 异常信号：如果TPS上升过程中波动大或者提前下降，说明服务器在负载增加时出现瓶颈，没法及时处理请求；如果峰值远低于预期，要么是服务器性能扛不住，要么是你的JMeter机器CPU/内存不够，撑不起1000线程并发。

三、Response Times Over Time（随时间变化的响应时间） #

横轴是时间，纵轴是请求的响应时间（一般单位是毫秒）。

• 正常趋势：前100秒，线程数增加导致服务器负载上升，响应时间可能缓慢变长；100秒全并发时响应时间达到最高；之后线程减少，负载降低，响应时间逐步回落。如果服务器性能足够，响应时间的增长幅度会比较平缓。
• 异常信号：如果响应时间突然飙升（比如从几十毫秒跳到几秒），说明服务器在某个负载点触发了瓶颈（比如数据库连接用完、CPU跑满）；如果大部分请求响应时间远超预期，说明服务器顶不住1000并发的压力。

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