带你了解如何分析Jmeter监听器常用图表并定位瓶颈

1.1 Jmeter监听器常用图表

目录

1.1 Jmeter监听器常用图表

1.1-1 查看结果树

1.1-2 汇总报告

1.1-3 集合报告

1.1-4 综合图 

1.1-5 断言结果

1.1-6 图形结果

1.1-7 响应时间图

1.2 Jmeter性能瓶颈定位

1.2-1 性能瓶颈产生的原因

1.2-2 性能瓶颈的解决方法

1.2-3 性能瓶颈如何定位

---

1.1-1 查看结果树

       查看结果树：调试利器。可以查看每个请求具体的详情，方便进行测试的比对。有点类似我们的抓包，可以看到request以及response信息。

 1.1-2 汇总报告

       汇总报告：为测试中的每个不同命名的请求创建一个表行。这与聚合报告类似，只是它使用更少的内存。

参数说明：

>> Label：取样器别名，如果勾选Include group name，则会添加线程组的名称作为前缀

>> # Samples：取样器运行次数

>> Average：请求（事务）的平均响应时间

>> Min：请求的最小响应时间

>> Max：请求的最大响应时间

>> Std. Dev：响应时间的标准方差

>> Error %：事务错误率

>> Throughput：吞吐量 也就是TPS

>> Received KB/sec：每秒收到的千字节

>> Sent KB/sec：每秒发送的千字节

>> Avg. Bytes：响应平均流量

1.1-3 集合报告

聚合报告：与Summary Report类似，但是表格中的内容有些许区别。

参数信息：

>>Label：取样器别名，如果勾选Include group name，则会添加线程组的名称作为前缀

>># Samples：取样器运行次数

>>Average：请求（事务）的平均响应时间

>>Median：中位数

>>90% Line：90%用户响应时间

>>95% Line：90%用户响应时间

>>99% Line：90%用户响应时间

>>Min：最小响应时间

>>Max：最大响应时间

>>Error：错误率

>>Throughput：吞吐率

>>Received KB/sec：每秒收到的千字节

>>Sent KB/sec：每秒收到的千字节

1.1-4 综合图 

       综合图：可以看到表格显示的结果与图形结果，看着挺复杂，其实稍微翻译一下就知道，绝大多数都是对图形的设置。

参数说明：
>>Column settings：

• Columns to display：选择要在图表中显示的列
• Rectangles color：单击右侧颜色矩形打开弹出对话框，选择自定义颜色。(就是点击)
• Foreground color：允许更改值文本颜色
• Value font：允许定义文本的字体设置
• Draw outlines bar?：在条形图上绘制或不绘制边界线
• Show number grouping?：是否显示Y轴标签中的数字分组
• Value labels vertical?：更改值标签的方向。（默认为水平）
• Column label selection：按结果标签过滤

>>Title：在图表的头部定义图表的标题

>>Graph size：根据当前JMeter窗口大小的宽度和高度计算图形大小。使用“ 宽度”和“ 高度”字段定义自定义大小。单位是像素

>>X   Axis settings：定义X轴标签的最大长度（以像素为单位）

>>Y   Axis settings：为Y轴定义自定义最大值

>>Legend：定义图表图例的放置和字体设置

>>Graph：图表形式显示，如下：

 1.1-5 断言结果

断言结果：会消耗大量资源（内存和CPU），性能测试时候不建议使用。

 1.1-6 图形结果

图形结果：也占用系统CPU，所以性能测试时候不推荐使用。

 参数说明：

>>样本数目：在这里，我们可以把样本数量简单理解成是jmeter一共向服务器发起了多少次请求

>>最新样本：jmeter最后一次发送请求的响应时间：单位是毫秒

>>平均：所有请求响应时间的平均值：单位是毫秒

>>偏离：标准方差，学过统计学的同学应该知道这个概念：如果你对这个概念一无所知也没有关系，偏离越小就代表测试的总体结果与平均值越接近

>>吞吐量：被测系统每分钟能处理的请求个数，这是判断服务器性能好坏的重要指标（也可以说是最重要的指标）：在上面的图形结果报表里我们可以看到系统的吞吐量是138.985每分钟，这就代表着系统每分钟可以处理138.985个请求

>>中值：就是响应时间的中间值，学术一点中值指的是有50%的值大于这个值，另外50%的值小于这个值：蒙圈了吧？实际上中值指的是如果有9个数，那么我们从小到大排列这些数，排在第5个的数就是这一组数的中值：那么如果有10个数呢？10个数的话第5个和第6个数的平均值就是这组数字的中值

1.1-7 响应时间图

响应时间图：响应时间图形监听器。有点和我们之前介绍的Aggregate Graph类似。

 参数说明：

>>Interval (ms)：X轴间隔的时间（以毫秒为单位）

>>Sampler label selection：按结果标签过滤。可以使用正则表达式

>>Title：在图表的头部定义图表的标题

>>Line settings：定义线条的宽度

>>Graph size：根据当前JMeter窗口大小的宽度和高度计算图形大小。使用“宽度”和“高度”字段定义自定义大小。单位是像素

>>X  Axis settings：自定义X轴标签的日期格式 

>>Y  Axis settings：自定义X轴标签的日期格式

>>Legend：定义图表图例的放置和字体设置

1.2 Jmeter性能瓶颈定位

1.2-1 性能瓶颈产生的原因

        jmeter能够监控的就是那么几个指标，最先反应问题的肯定是响应时间，事务的成功率。如果响应时间和成功率，其中有一个不符合要求，那么就需要来定为瓶颈出现在哪。一个性能瓶颈可能出现的地方拥有很多种可能，应用系统的从前到后任何一个环节都有可能。前端、后端、数据库、操作系统，甚至网络，包括硬件问题，都有可能是导致出现性能瓶颈的地方，那我们作为测试工程师，最终的目标就是要定为到问题的发生点。瓶颈产生在以下几方面：

1. 网络瓶颈：如带宽，流量等形成的网络环境
2. 应用服务瓶颈：如中间件的基本配置，CACHE等
3. 系统瓶颈：这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
4. 数据库瓶颈：以ORACLE为例，SYS中默认的一些参数设置
5. 应用程序本身瓶颈：这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位。

1.2-2 性能瓶颈的解决方法

       逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。  

1、怀疑内存不足时：当内存不足时，有些进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上
>>方法一：

• 监控指标：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec。
• 参考值：如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。

>>方法二：根据Physical Disk 值分析性能瓶颈

• 监控指标：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length。
• 参考值：%Disk Time建议阈值90%。

2、怀疑内存泄漏时：

>>监控指标：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

>>说明：Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验

3、CPU分析

>>监控指标：

• System %Processor Time CPU，Processor %Processor Time CPU
• Processor%user time 和Processor%Privileged Time
• system\Processor Queue Length
• Context Switches/sec 和%Privileged Time

>>参考值：

• System\%Total processor time不持续超过90%，如果服务器专用于SQL Server，可接受的最大上限是80-85% ，合理使用的范围在60%至70%。
• Processor %Processor Time小于75%
• system\Processor Queue Length值，小于CPU数量的总数+1

4、CPU瓶颈问题：

>>指标分析：System\%Total processor time如果该值持续超过90%，且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈。注：在某些多CPU系统中，该数据虽然本身并不大，但CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈

>>排除内存因素：如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上）

5、造成CPU使用率高的原因：

>>频繁执行程序，复杂运算操作，消耗CPU严重

>>数据库查询语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出现瓶颈

>>内存不足，IO磁盘问题使得CPU的开销增加

 6、磁盘 I / O分析

>>监控指标：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer

>>参考值：%Disk Time建议阈值90%。Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

• Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大， 那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。
• Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了.
• Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势
• Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈
• Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
• Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
• Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）
• Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

1.2-3 性能瓶颈如何定位

1. 查看系统日志，日志是定位问题的不二法宝，如果日志记录的全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，我们就可以顺藤摸瓜，很快定位到导致内存溢出的问题在哪里。
2. 利用性能监控工具，比如：JAVA开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。利用Spotlight可以监控数据库使用情况。我们需要关注的性能点有：CPU负载，内存使用率，网络I/O等。
3. 工具和日志只是手段，除此之外，还需要设计合理的性能测试场景

具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等。好的测试场景，能更加快速的发现瓶颈，定位瓶颈。

     4. 了解系统参数配置，可以进行后期的性能调优。

小结：做性能测试的时候，我们一定要确保瓶颈不要发生在我们自己的测试脚本和测试工具上。