51Testing软件测试论坛

标题: LR压力测试结果分析探讨 [打印本页]

作者: oceanmeng    时间: 2007-11-2 17:14
标题: LR压力测试结果分析探讨
压力测试报告分析 (有兴趣的朋友一起探讨一下压力测试后的分析!图没有上传,有兴趣的朋友可以发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左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时,测试服务器的硬件配置和实际服务器的配置还有一定的差距!
作者: hehemeimei    时间: 2007-11-2 17:47
真好。本来想顶,后来一想,不能只写顶了。
作者: TransferForTest    时间: 2007-11-3 11:12
分析的挺透彻, 就是看不到图. 顶
作者: msnshow    时间: 2007-11-3 11:17
写得不错,值得发扬!!!
作者: hbxtly    时间: 2007-11-3 12:03
学习学习
作者: 1qazse4    时间: 2007-11-3 15:16
分析得真详细,很感谢楼主,支持!
作者: christina11    时间: 2007-11-12 23:41
标题: up
up
作者: 未来战士    时间: 2007-11-13 10:56
sdlkfj1
作者: zhangsq1982    时间: 2007-11-13 12:35
good ,better,best!!
作者: zoddy    时间: 2007-11-13 13:36
楼主分析不错!能否来份带图的?邮箱pq2006us@yahoo.com.cn
作者: cuizhihui    时间: 2007-11-13 14:59


真是太经典的分析了!
作者: pupu840323    时间: 2007-11-13 15:00
这东西不错呀,楼主我的邮箱qujf@icss.com.cn
等待你的带图片版了
作者: ghx    时间: 2007-11-13 16:36
帖子分析的很好,如果能够在把LR分析的图给加上更完美了!
作者: bluemoon1999    时间: 2007-11-14 08:46
不错,能发送图片过来吗 ?
我也研究下.
EMAIL:  zxyblue1999@163.com
作者: jiyangao    时间: 2007-11-14 11:33
谢谢楼主,希望可以看见带图的
gaojiyang@sccl.cn
作者: hiyouhiyou    时间: 2007-11-14 12:17
精华啊!谢谢分享
作者: chuhaiyan    时间: 2007-11-14 15:28
chuyanh@yahoo.com.cn  
先谢了
作者: ningning_lu    时间: 2007-11-14 16:31
狂顶!
我也需要图啊,luningning@gmail.com
作者: 水仙花    时间: 2007-11-15 10:29
急需
xy@kiloboat.com
谢谢啊
作者: hongtang    时间: 2007-11-15 10:57
标题: 我看了以后有几个问题想和大家一起聊以下
1。本次压力的测试并发用户数量是多少,增加用户的策略是什么?持续时间是什么?对应的 think time ,pacing time 是多少。每小时的事务处理量是多少?
2。本次压力的测试网络拓扑结构是什么?
3。并发数迅速增加前后的值在400左右!-是指数据库连接?webserver 连接? app 连接?
4. Linux资源监控中指标CPU占用率持续超过80% 是应用?数据库? 是那些进程占用的cpu最多?
5 你的中间建是什么操作系统?
6 数据库后台有无死锁?活动锁?TOP-SQL有无?
7 controller里是否报错信息? 数量? 原因?
能提供下吗?
作者: ceceily    时间: 2007-11-15 12:15
好文,能否提供图片呢?ceceily@yahoo.com
谢谢!
作者: hibetty    时间: 2007-11-15 16:07
标题: 回复 1# 的帖子
太强了。学习中,虽然有些看的还不大明白
作者: chenyq    时间: 2007-11-15 16:48
谢谢楼主!分析透彻,顶~~~ chenyq@mail.si.net.cn
作者: bluemoon1999    时间: 2007-11-16 10:31
21楼正确.
压力测试 是指定条件下的.
楼主应该说明,无连接时间点的 系统虚拟用户情况,以及 这一时间点的 性能计数器,数据库情况.

个人觉得:
压力测试,使用不同的策略,对应不同的压力测试结果.

测试策略  对应,脚本使用情况,对应 应用服务器,数据库,操作系统 这样一套结论才能分析出 一种策略的 测试结果.

不能够凭一种结果 就得出结论.
作者: 13959202    时间: 2007-11-16 11:22
标题: 回复 1# 的帖子
楼主好人 做好事 请给我一份billy-yang2001@hotmail.com
作者: laohan0719    时间: 2007-11-21 16:17
看看图片能更好的分析 呵呵呵 支持楼主 chaohao@163.com
作者: liguoming1227    时间: 2007-11-21 16:30
楼主,我也想看带图的,能发一份给我吗?万分感谢
lisixian1227@163.com
作者: yoolika    时间: 2007-11-22 16:16
我也要一份~babyer@qq.com
作者: charles_131    时间: 2007-12-14 09:19
看了要顶
作者: charles_131    时间: 2007-12-14 09:20
好贴 再顶一次
作者: hmilyjch    时间: 2007-12-14 10:15
我也想看看图 hmilyjch@163.com
作者: whyan02002    时间: 2007-12-14 10:45
楼主,我也想看带图的,能发一份给我吗?谢谢!
why-76@163.com
作者: ld_abc    时间: 2007-12-14 14:06
我也想要一份,ld_abc@163.com,谢谢楼主。
作者: jinghuayu    时间: 2007-12-14 20:23
顶,不错
作者: 泰德李    时间: 2007-12-14 21:35
很想要带图的,tadlee@126.com 不胜感激
作者: gaoyoumei    时间: 2007-12-16 00:35
非常期望带图的分析啊!顶楼主的帖子!gaoyoumei@sina.com
作者: 天使之泪    时间: 2007-12-20 11:41
刚才看见一个一摸一样的帖子.不知道是谁抄谁的.到处发
作者: wine_test    时间: 2007-12-21 18:30
喜欢这类的帖子,一直在找这类资料呢,不错
作者: senciya    时间: 2007-12-26 10:50
对我太有用啦,谢谢楼主
作者: moonsun646    时间: 2007-12-26 11:34
标题: 学习
学习
作者: silencesnow    时间: 2007-12-27 13:07
学习
作者: qinshuxia    时间: 2008-5-20 17:57
做个标记
作者: lihe0226    时间: 2010-7-16 19:17
lz真厉害
作者: jethua    时间: 2011-8-9 10:06
不错,学习中,多交流
作者: zhang.yuandong    时间: 2011-8-10 11:24
好贴都要经历时间啊
作者: yandaju    时间: 2011-8-15 11:25
正在学习。多谢了 !
作者: aishasha    时间: 2011-10-18 15:56
正在研究,先收藏的,谢lz~
作者: xiaoyaoac    时间: 2012-1-18 18:12
挺好的 只是没图片
作者: 点点滴滴2010    时间: 2012-3-2 18:32
回复 1# oceanmeng
希望楼主提供图!我的邮箱:hanj@gasgoo.com     O(∩_∩)O谢谢
作者: shuikuai    时间: 2012-3-29 11:27
初学者,很有启发,谢谢楼主。
作者: 778856    时间: 2012-5-23 12:01
回复 8# 未来战士
作者: iter777    时间: 2012-5-23 15:10
支持一下,最近也想找找压力测试的分析方法




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2