LR压力测试结果分析探讨 ZT

文章来源互联网。

LR压力测试结果分析探讨 ZT

压力测试 报告分析 （有兴趣的朋友一起探讨一下压力测试 后的分析！图没有上传，有兴趣的朋友可以发mail给我！）

分析原则：

1.具体问题具体分析（这是由于不同的应用 系统 ，不同的测试目的，不同的性能关注点）
2.查找瓶颈时按以下顺序，由易到难。
    服务 器 硬件瓶颈  网络 瓶颈（对局域网，可以不考虑） 服务 器 操作系统 瓶颈（参数配置） 中间件瓶颈（参数配置，数据 库 ，web服务 器 等） 应用瓶颈（SQL语句、数据 库 设计 、业务 逻辑、算法等）
   
分析的信息来源：
1 根据场景运行过程中的错误提示信息
2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：
1．Error: Failed to connect to server “172.17.7.230″: [10060] Connection
Error: timed out Error: Server “172.17.7.230″ has shut down the connection prematurely

分析：
A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题，实际测试中多半是服务器链接的配置问题）

B、应用服务没有死（）
（应用服务参数设置问题）
        对应的Apache和tomcat的最大链接数需要修改，如果连接时收到connection refused消息，说明应提高相应的服务器最大连接的设置，增加幅度要根据实际情况和服务器硬件的情况来定，建议每次增加25%！

C、数据库的连接
(数据库启动的最大连接数 （跟硬件的内存 有关）)

D、我们的应用程序spring控制的最大链接数太低

2 Error: Page download timeout (120 seconds) has expired

分析：

A、应用服务参数设置太大导致服务器的瓶颈
B、页面中图片太多
C、在程序处理表的时候检查字段太大多
D、实际测试时有些资源需要请求外网，而我们的测试环境 是局域网环境
3 Error  “http://172.17.7.230/Home.do.... ”

分析：
        A、脚本 设计错误，造成页面异常。服务器有响应！
        B、并发数过大，造成服务器响应延迟。

4 Error page “text=xxxxx”

分析：
        A、脚本设计问题，例如，前一脚本修改了某些内容，造成后面的脚本访问异常。
        B、不确定因素，有时候回放正常的脚本，一放到场景中就出现这样的错误。只能反复修改脚本！

二．监控指标数据分析
1．Vusers数
        Loadrunner 系统设置的虚拟用户数目。Vuser去实际调用事先制作的脚本文件中的应用。
        每个Vuser产生响应的操作，所有的操作对服务器形成并发。
       
颜色        比例        度量        图最小值        图平均值         图最大值        图中间值        图SD
        1        Run        0.0        21.25        44        41        21.276

        在实际测试中，Vusers可以根据实际情况的需要，在测试过程中增加或者减少。

2．最大并发用户数：

颜色        比例        度量        最小值        平均值        最大值        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

应用系统在当前环境下能承受的最大并发用户数。
    在方案 运行中，如果出现了大批用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
        从上图可以看出：在测试运行到4个小时左右的时候，apache的点击数/秒开始迅速增加！

3．业务操作响应时间：

    使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

颜色        比例        度量
        1        最小值
        1        平均值
        1        最大值
        分析事务的响应情况，要每次详细分析，目前还只能观察到响应时间过长的事务！

4．每秒点击数
        负载测试 期间每秒内 Vuser 在 Web 服务器上点击的次数。可根据点击次数来估算 Vuser 生成的负载数。


颜色        比例        度量        图最小值        平均值        图最大值        图中间值        图SD
        1        点击次数        69.908        105.736        130.244        103.666        12.186

        从图中不难看出，在4小时的时候，点技数明显增高。和apache的每秒点击数增大的时间相吻合！

5．吞吐量
        负载测试期间 Web 服务器上的吞吐量(字节)。吞吐量表示在任何指定秒内 Vuser 从服务器接收到的数据量。此图可估计 Vuser 生成的负载量(服务器吞吐量)。

颜色        比例        度量        图最小值        平均值        图最大值        图中间值        图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左右！分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距！