Lr_结果分析

脚本跑完后，打开结果报告，分析结果。

 

分析结果页面默认的有5个图，Sunmary Report 那个是默认的概要信息。

除了那5张图，右击，点下图的按钮，可以添加图，里面有很多图

 

lr中分析结果性能指标一个是响应时间、一个是吞吐量，就这2个，只要把握住这个原则，所有的图出来都能判断。它会换不同的角度去看响应时间、看吞吐量。

 性能测试结束了，希望先看的是：响应时间、tps（性能能不能满足，就是看响应时间能不能达到要求，吞吐量满足业务需求不）

 

1、分析结果，应该先看成功率，我们脚本跑完了，一共1000个业务，失败了900个业务就别去分析了，没意义。

如果你压的过程中出现了好多错误，在这个错误的基础之上来分析你的性能指标是没有说服力的，性能再好，功能一定是要正确的。

失败了要看失败比例，失败少的话无所谓，我们人跑的话也是可能会失败的

1）成功率其实在controller中就可以看

2）在结果分析页面我们看Transaction  Summary 事物图也能看出来成功没成功，图下方的列表里成功了是pass，没成功是fall，并会显示红色，

咱目前是发了多大帖子？是749吧，一眼就能看见。

 

3）除了看分析报告之前我们可以看看系统中，之前是2358，加749，可以看到都成功了。这是最准确的查看成功没成功的方法。

 

 

2、看用户数，（分析压力有没有上去，服务器有没有感受到这个压力）

这个图 用户没有失败的，一直在上升，只是说明有人在施压，不能说明这压力是增加到咱们这个服务器上去了

hits每秒点击次数，用户向服务器端发送的一次请求就是一次hit，客户端点一下，服务器端回应你一下才叫一次点击。

用户越多，点击次数不一定越高，到了一定程度，服务器端反应不过来，不能回应客户端，点击次数就会趋于平稳或降低。

 

接一下来我们来画一个图，一条表示时间，一条表示压力，蓝色线代表用户数（备注：压后的服务器的利用率40%多，说明压力没传到服务器上）

用户数到A点的时候，点击次数变平缓，用户数再继续增加的时候，hps没增加，意味着客户端给的压力够大了，但是吞吐量hps上不去，看hps和tps是一样的。都可以表示吞吐量。

 用户数增加，为什么hps不增加了呢，排查瓶颈的问题。

比如我们现在是1万个用户，用户在增加tps平缓，这就不是用户的事，是你压力机的问题。出现阻塞，1万个线程，在排队，根本就没压过去

3、用户数和hps图去对比看

 

hps：是个吞吐量的指标（pv、tps、hps、throughput都可以叫吞吐量，看趋势）

 

压力是不是到极限了。你可以拿着用户数和hps图去对比看。（hps图要看他的趋势，随着用户数的增大，hps也慢慢增大；如果用户数增大，hps不增加了，说明可能卡在哪个地方了或者到极限了）

我们把两个图合并到一起。在用户图右键选下图中按钮，在弹出的窗口选择要合并的图，点OK。

 

合并后的图片如下图。从图中我们可以看出，每8s绘制1个点。

可以把这个时间间隔设置的小点，最少是5s。每5s绘制一个点，这样点就会多了。

 

看合并后的表，压力上去了没有？

看整体趋势，其实已经到极限了，我们右键点， view cursor（查看光标），这样看很方便。鼠标上有两个十字线

下图我们可以看到用户数是4，时间是15s，点击数大概是200做个有

当用户数为6个时，点击数是400。光标的中心点和用户数线交汇的时候看左边，和点击次数线交汇的时候看右边。

用户数到8个的时候，可以看到，点击数并没怎么增加。

用户数到10个的时候点击数也没怎么增加，后面点击数还下降了，再后面高了，点，不过高的也不多。

从图中我们可以看到，用户数在6个的时候，吞吐量（hps）基本上就不怎么变化了。

我们取个平均值吧，平均值大概在用户数是7、8个的时候，点击次数不再变化。为什么？

 

4、看下操作系统资源利用率，看看资源是不是满了呢，我们可以打开图，如下图：

 我们看到有好多图，我们看一个就可以。把不想看的复选框勾取消就可以。

这比例的意思：10是因为这个值太小了，在图中没显示，所以放大了10倍。真实值是列表中的值。

咱们这里面数据非常大，有的指标非常高，像咱们上下文切换这个，4千多。这就需要我们去缩小，缩小了100倍，0.01。4千多乘以0.01就是在图中显示的数据。

下面我们看cup的值是1，没放大也没缩小。

看到CPU利用率平均值是48点多，做大是69点多。我们的CPU没有满。

cup没满，压力上不去？是网络的原因，因为这个机器用的是无线网（走虚拟机，设置为桥接模式，走的就是无线网。设成host模式，就是共享的带宽）。

压力机换为网线，帖子发的多，cpu也很快就90多了。

做性能测试去压服务器，要确保网络环境是有线网。无线不靠谱。

现在你看下图我们的业务通过了一千多个了，但是TPS上不去了，这次是为什么？

因为我们的CPU满了。你去监控咱们的CPU的话，就是一条线。

 

5、计算下载量

脚本跑完后，下载了多少数据量，跑了5分钟。

100兆带宽相当于最大下载速度多大？100兆100Bit  二进制  下载速度字节byte

 100除以8是12.5兆

1B=8b

 6、换网线后，压测

脚本跑完看分析结果。事物数是两千多个，就是发了两千多个帖子

用户数也没失败的，再把用户数和hps合并一下，

用户数到6个以上的时候，hps基本上没太大变化。 我们看一下资源利用率，会到看cup已经满了

 

资源利用率cpu图，也可以和我们的用户数图去合并一下。我们看到当用户数为10个左右的时候cup就满了

 

一般我们的cup到75%以后我们的压力就开始上不去了，吞吐量就趋于平衡

也可以拿资源利用率去和hps去合并。如下图，资源利用率在85%左右，hps基本平衡

 

所以咱们这个系统性能是没有什么问题的。

 

第一轮压吞吐量上不去，资源利用率上不去，认为是带宽的问题。

然后换带宽。换完带宽可以了。这就可以写测试报告了。