lr的测试结果怎么分析？

Posted 2023-05-11

比如：吞吐量说明什么问题？每秒点击率说明什么问题？

1.具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
2.查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈 �8�1 网络瓶颈（对局域网，可以不考虑）�8�1 服务器操作系统瓶颈（参数配置）�8�1 中间件瓶颈（参数配置，数据库，web服务器等）�8�1 应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

分析的信息来源：
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据

颜色 比例 度量 图最小值 平均值 图最大值 图中间值 图SD
1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473

同样，从图中可以看出，在4个小时的时候，web服务器的吞吐量开始增高。在图中还可以看到吞吐量的走势图，从开始到进行到4个小时反弹之前呈降低的趋势，这是因为系统在初期调用的资源都是直接来之服务器，运行一段时间后系统的部分资源来自缓存。

6．下载组件大小
每个页面的组件大小，且包括组件的标头的大小！

页面组件大小的分析表格比较复杂，实际分析中可以通过loadrunner的报告分析工具来分析。页面组件大小分析主要是找到页面中比较庞大的组件，如果其影响到了页面的下载速度，则要想办法将其改小！

7．Apache资源
显示APACHE web服务器上的资源摘要。前面已经提到过以并发点击数为主。

颜色 比例 度量 最小值 平均值 最大值 SD
100 Apache CPU 使用情况(Apache):172.17.7.210 0.777 0.852 0.93 0.043
0.01 已发送 KB/秒(Apache):172.17.7.210 6 1430.371 2689.333 327.924
0.1 点击次数/秒(Apache):172.17.7.210 0.333 114.352 533.667 40.201

三．服务器资源监控指标：
（目前通过top监察）
内存：
Linux资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈！

内存资源成为系统性能的瓶颈的征兆:
很高的换页率(high pageout rate);
进程进入不活动状态;
交换区所有磁盘的活动次数可高;
可高的全局系统CPU利用率;
内存不够出错(out of memory errors)

处理器：

Linux资源监控中指标CPU占用率持续超过80%（对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95％），表明瓶颈是CPU。
实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86％以上！
说明，目前系统用应用的cpu也是测试的瓶颈！

CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU)
过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time)

四．数据库服务器：
数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈！

五．结论
以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。
根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！ 参考技术A http://www.cnblogs.com/hicome/archive/2007/11/05/949848.html

LR的响应时间与使用IE所感受时间不一致的讨论

在做性能测试时，有时碰到这样一种情况，使用性能工具LR测试出来的响应时间比实际使用IE感受到的时间要长，例如，实际使用IE打开一个系统时只需要1~2秒，而使用LR跑一个用户所得出的结果可能是8秒、10秒、或者更大的响应时间。

 

针对上述问题进行分析总结，有3种情况：

1、在运行LR场景时没有忽略Think Time（思考时间）和记录log的时间；

2、测试机配置不高，比如低配置的机器在运行场景工具时系统资源已满，则造成响应时间过长。

3、实际IE感受的时间不等同于LR录制的响应时间。

 

    前两中情况可以通过LR设置及提高硬件配置解决。

    第三种情况，因为LR在录制过程中，事物的响应时间包括：DNS Resolution、Connection、First Buffer time、Receive Time、Client Time时间等，比如当我们在使用IE打开页面时，系统首先会进行域名解析，并与服务器建立连接、下载数据，到这时在IE中已可以显示页面，但实际响应时间并没有结束，浏览器仍有可能在与服务器进行数据交互，或者客户端IE由于忙碌未及时将请求发出，出现了客户端延时情况（客户端IE会执行一些JavaScript脚本或其他页面初始化动作），直到这些动作全部完成后才是一个完整的响应时间，LR也是记录的这个响应时间。

 

    所以我们通常使用IE所感受到的时间是比用性能工具录制时记录的响应时间要少。因此，系统页面的响应时间应以工具记录时间为准，并在分析报告中查看平均事物响应时间。

 

                                                                                                                               

--------

对时间的解释：

1、DNS Resolution：浏览访问一个网站的时候，一般用的是域名，需要DNS服务器把域名解析为IP地址，这个过程就是域名解析时间。

2、Connection：解析出WebServer的IP地址后，浏览器请求被发送到了一个Web Server，然后浏览器和Web Server 之间需要建立一个初始化的HTTP连接，服务器端需要做两件事：一个是接收请求，二是分配进程。建立该连接的过程就是Connection。

3、First　Buffer：建立连接后，从Web Server发出第一个数据包，进过网络传输到客户端，浏览器成功接收第一个字节的时间就是First Buffer。

4、Receive：从浏览器接收第一个字节起，直到成功收到最后一个字节，下载完成为止。

5、Client Time：请求在客户端浏览器延迟的时间。

在实际使用LR做页面请求响应时间时，我采取的是下载页面，清除IE缓存，每次都是不同用户浏览，所以对服务器的压力比较大，每秒的请求数居高，但是得到的responsetime确实比手动的时候大了很多，个人认为，图片在加载过程中及CSS样式文件，都是同步在加载，但是对IE客户端来说，人的视觉首先会看到图片，然后才是样式的出现，所以感觉上要快，因为看到的是一个动态过程，但是对LR来说，它只关心，从第一次请求到最终结束请求的时间，因此时间上会比实际操作时要长。

举个例子，或许就是一个图片链接，但是他加载的可能一个超级链接，但是这个链接又是用ajax来实现的，另外还带有CSS，但是对IE端用户来说，只要看到图片就认为加载完毕了！

例如，我们需要衡量服务器处理一个请求的平均响应时间。考虑，服务器端能同时并发处理的请求数一定，当性能测试发送的每秒请求数超过它能处理的请求数后，再到达的请求将会在服务器系统中排队等待，这时，整个响应时间的计时已经开始，排队等待时间将会计入响应时间。所以，如果LR仍然持续发送请求，可能造成接下来的请求都在等待。这时，服务器每次处理的事务数在下降，平均响应时间在增大，造成了请求发送越快，处理越少越慢。

　　对于这种情况，从服务器端出发，来考虑设置请求发送的速度。”

　　悟石：“从服务器端来看，让每颗CPU都忙碌起来，是件好事。当压力超过CPU能承受范围时，认为是过载，等待队列会越来越长，load不断飙升。

其实LoadRunner 是以客户端的角度来定义“响应时间”的，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载，但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果，设置步长则可以缓解这一情况，这样，应该试试设置pacing，再运行看看情况

 

后尝试配置pacing为delay30s， 场景结果有所改变。需要仔细了解其中原理。