概述
jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈
本文以500线程的阶梯加压测试结果来描述图表。
常用监听器
1：Transactions per Second
监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。
最大TPS大约在140左右，从1分26秒左右，开始有未通过的事物
2：Hits per Second
动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。
点击率波动较大，且不能持续上升。说明性能很不稳定
3：Response Times Over Time
监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒）
响应时间在4950ms左右开始稳定下来，后续又经历一次大的波动
4：Response Times vs Threads
线程活动期间的响应时间监听。其中横坐标是活动的线程数（也就是并发数），纵坐标是响应时间（单位是毫秒）
5： Active Threads Over Time
监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数）
6：Response Times Percentiles
监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间。此图表示有99.7%的请求响应时间在5s以内。
7：Response Times Distribution
响应时间分布的柱状图。其中横坐标是柱状分布图，纵坐标是响应时间。此图表示大约有111个请求响应时间在5076ms。
8：Composite Graph
组合式的监听器。其中横坐标是运行时间，纵坐标是各性能数据的汇总值（其中有一些数据需要除以10）。
总结
不同的监听器可以监听不同的性能数据，但是想要在图表中直观的分析出性能的瓶颈，就需要组合式的监听器。例如通过响应时间和吞吐量的分布得出吞吐量的拐点。
通过以上图表能看出来，在持续加压的事物场景中，99.7%的请求响应时间都控制在了5s以内。
性能指标监听
概述
性能测试过程中，想要得到比较靠谱的性能数据，就不得不对各种性能数据进行动态监听。jmeter中提供了很多性能数据的监听器，我们通过监听器可以来分析性能瓶颈
本文以500线程的逐渐加压测试结果来描述图表（压测百度）
常用监听器
Transactions per Second
监听动态TPS，用来分析吞吐量。其中横坐标是运行时间，纵坐标是TPS值。红色表示通过的TPS，绿色表示失败的。
可以看出在56s左右，tps达到最高点1202/s，之后开始直线下降。
Hits per Second
动态监听单位时间的点击率，也就是触发的请求数。其中横坐标是运行时间，纵坐标是HPS值。
可以看出在58s的时候，点击率出现波动；一分钟的时候，点击率达到最大（996/s），之后直线下降
Response Times Over Time
监听整个事物运行期间的响应时间。其中横坐标是运行时间，纵坐标是响应时间（单位是毫秒）
响应时间在达到3233ms之后左右开始急剧上升，此处就是性能瓶颈
Response Times vs Threads
线程活动期间的响应时间监听。其中横坐标是活动的线程数（也就是并发数），纵坐标是响应时间（单位是毫秒）
Active Threads Over Time
监听单位时间内活动的线程数。其中横坐标是单位时间（单位是毫秒），纵坐标是活动线程数（也就是并发数）
Response Times Percentiles
监听响应时间分布的百分比。其中横坐标是请求数的百分比，纵坐标是响应时间。此图表示有90%的请求响应时间在270ms以内。
Response Times Distribution
响应时间分布的柱状图。其中横坐标是柱状分布图，纵坐标是响应时间。
Composite Graph!
组合式的监听器。其中横坐标是运行时间，纵坐标是各性能数据的汇总值（其中有一些数据需要除以10）
此图表示运行到一分钟左右，吞吐量达到瓶颈点，之后吞吐量急剧下降，响应时间急剧上升
这里是对每个插件的用处进行解释：
PerfMon Metrics Collector：用于监控机器的CPU、Memory、swap、Disks I/O、Networks I/O。CPU：cpu占用量百分比；
Memory：存储量的使用情况；swap：交换区的使用情况；Disks I/O：磁盘I/O；Networks I/O：网络I/O
Hits per Second：每秒测试计划所产生的点击服务器的次数。
Bytes Throughput Over Time：在压力测试期间接收和发送的bytes数。
Composite Graph：将你的测试计划中的所有图表集合在同一张图表中以方便查看。
Response Codes per Second：每秒返回的响应码，表明jmeter测试期间，随着时间的推移返回的响应码，从中我们可以看到测试期间在哪个时间段内出现了错误，就可以分析在该时间内系统的什么环境因素导致的错误。
Response Latencies Over Time：每秒钟的响应等待时间，表明jmeter测试期间，随着时间的推移，系统的响应等待时间的变化，也是系统随着时间推移系统效率的变化。
Response Times Distribution：响应时间分布，X轴表示的是响应时间，Y轴表示的是响应次数，F（X,Y）表示系统在某种响应时间次数是多少，如果响应时间短的地方，响应次数多，说明系统的效率越高。
Response Times Over Time：每秒钟响应时间，X轴表示的是系统运行的时刻，Y轴表示的是响应时间，F（X,Y）表示系统随着时间的推移，系统的响应时间的变化，可以看出响应时间的稳定性。
Response Times Percentiles：响应时间的百分比，X轴表示的是百分比，Y轴表示的是响应时间，F（X,Y）表示低于某个百分比的响应时间，比如有80%的响应低于400ms。
Response Times vs Threads：响应时间用户数，X轴表示的是活动线程数，也就是并发访问的用户数，Y轴表示的是响应时间，F（X,Y）表示在某种并发量的情况下，系统的响应时间是多少。
Transaction Throughput vs Threads：每个活动线程数的事务吞吐量，X轴表示的是活动线程数，Y轴表示的是事务吞吐量，F（X,Y）的含义是当系统处于某个活动线程数时，系统当时的事务吞吐量是多少，比如当有10个活动线程时，事务吞吐量是100/s，而当有20个活动线程时，事务吞吐量是50/s，说明随着用户访问的增加，系统的处理效率开始下降了，从这个图中可以找到一个临界点，在多大的活动线程数时，系统达到最大的吞吐量。
Transactions per Second：每秒的事务数，X轴表示访问结束的时刻，Y轴表示访问量，F（X,Y）表示在某个结束时刻，一共有多少的访问量结束访问。
Active Threads Over Time：每秒的活动线程数，X轴表示访问的时刻，Y轴表示活动线程数，F（X,Y）表示某个时刻的活动线程数