51Testing软件测试论坛

标题: 性能测试(并发负载压力)测试分析-简要篇 [打印本页]

作者: 笑游天涯侠    时间: 2005-12-21 16:22
标题: 性能测试(并发负载压力)测试分析-简要篇
在论坛混了多日,发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试,但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,希望能对大家分析测试结果有所帮助。

分析原则:
    • 具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
    • 查找瓶颈时按以下顺序,由易到难。
    服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
    注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

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

一.错误提示分析
分析实例:
1 •Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
  •Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

  分析:
•A、应用服务死掉。
   (小用户时:程序上的问题。程序上处理数据库的问题)
•B、应用服务没有死
   (应用服务参数设置问题)
    例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
•C、数据库的连接
   (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))

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

分析:可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈
•B、页面中图片太多
•C、在程序处理表的时候检查字段太大多

二.监控指标数据分析
1.最大并发用户数:
应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。
在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2.业务操作响应时间:
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
• 如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问题
3.服务器资源监控指标:
内存:
    1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,则很可能存在内存泄漏。

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

处理器:
    1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%
    合理使用的范围在60%至70%。
    2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

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)

磁盘I/O:
    1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
    2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :
     过高的磁盘利用率(high disk utilization)
    太长的磁盘等待队列(large disk queue length)
    等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

4.数据库服务器:
SQL Server数据库:
    1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。如果持续低于80%,应考虑增加内存。
    2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
    3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,并且会导致恶劣的用户体验。该计数器的值必须为0。
   4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。

Oracle数据库:
  1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,那么需要增加SHARED_POOL_SIZE的大小。
    快存(共享SQL区)和数据字典快存的命中率:
   select(sum(pins-reloads))/sum(pins) from v$librarycache;
    select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    自由内存:    select * from v$sgastat where name=’free memory’;
2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
  缓冲区高速缓存命中率:
    select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ;
   
    Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
    日志缓冲区的申请情况 :
     select name,value from v$sysstat where name = 'redo log space requests' ;
4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
   内存排序命中率 :
     select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts (disk)' and b.name='sorts (memory)'
   
    注:上述SQL Server和Oracle数据库分析,只是一些简单、基本的分析,特别是Oracle数据库的分析和优化,是一门专门的技术,进一步的分析可查相关资料。

说明:
    以上只是个人的体会和部分资料的整理,并不代表专家之言。算抛砖引玉,有不同看法和更深入的分析的,希望大家勇要发言,以推动我们国内的性能测试工作。

[ 本帖最后由 笑游天涯侠 于 2005-12-21 16:37 编辑 ]
作者: Koffer    时间: 2005-12-21 16:29
so nice.
作者: 大漠飞鹰    时间: 2005-12-22 08:56
顶!
作者: angel_test    时间: 2005-12-22 09:11
顶,写的不错:)
作者: xyuan007    时间: 2005-12-22 09:32
不错。不过有些资料好像有点旧啊!
oracle缓冲命中率,LZ提供的是8i的方法,在9i中DB_BLOCK_BUFFERS已废弃不用,应该调整DB_CACHE_SIZE参数值,

[ 本帖最后由 xyuan007 于 2005-12-22 10:57 编辑 ]
作者: tiny403    时间: 2005-12-22 10:44
标题: to 笑傲天涯侠:
对我现在的测试很有启发!!!:)
作者: marigold    时间: 2005-12-22 15:28
笑傲天涯侠:
写得很好呀!崇拜!
有msn 什么的吗?想认识你!多多交流!:)
作者: jane830527    时间: 2005-12-23 15:31
很好
作者: Zee    时间: 2005-12-24 19:15
支持一下。希望国内的测试人能有free的精神。

一直以来,我都认为测试人员的素质都很好。
作者: jingling8825    时间: 2005-12-26 11:30
非常棒的经验, 谢谢楼主!学习中……
作者: 小背    时间: 2005-12-26 13:09
标题: 很棒
非常有用的资料,最近一直在学习,也就是会些简单的东西,但是深入一点就不会了,以后要更加努力的学习,能拿出点成绩让大家一起分享!!
作者: roy366    时间: 2005-12-26 14:01
ding
作者: 笑游天涯侠    时间: 2005-12-27 09:55
标题: 谢谢大家的支持
总想把自己在性能测试中的一些经验和体会拿出来与大家共享,可是总没有时间。等什么时候有空了,我再把它们整理好奉献给大家。
作者: fzzqd    时间: 2005-12-28 10:25
赞一下
作者: anna_lu2003    时间: 2006-2-7 11:18
一个字好,两个字很好,三个字非常好
作者: lijia0912    时间: 2006-2-7 11:56
初步入门阶段,有些东西好像看不懂啊
作者: juiwo    时间: 2006-2-7 12:53
顶先
作者: hicome    时间: 2006-2-11 19:06
原帖由 笑游天涯侠 于 2005-12-27 09:55 发表
总想把自己在性能测试中的一些经验和体会拿出来与大家共享,可是总没有时间。等什么时候有空了,我再把它们整理好奉献给大家。


-------等待楼主实现这句话,但不要我们等得太久啊!!!!!!!:)

----楼主,如果数据库是MySQL的呢,性能指标怎样才是最好的?

[ 本帖最后由 hicome 于 2006-2-11 19:10 编辑 ]
作者: yongjun4    时间: 2006-2-16 13:04
标题:
lz说的很有见地!~~~~
作者: 李zi    时间: 2006-2-16 13:21
标题: 正不知如何下手呢!!
多谢搂住!
作者: youandme    时间: 2006-2-16 20:14
偶也遇到许多问题,看了有些帮助. 顶一下!
作者: fengchuanbin    时间: 2006-2-17 10:54
谢谢~~写的很好
作者: mailtolily    时间: 2006-2-17 11:38
标题: 参数设置
楼主,感谢你共享文章。
在你的文章中多次提到的“参数配置”,对性能有很大也很重要的关系;请问你针对
服务器操作系统、中间件瓶颈等如何进行参数配置?
作者: mojinde    时间: 2006-2-17 15:31
好文不能不顶
作者: jackei    时间: 2006-2-17 16:52
1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

——还要考虑页面错误的情况;


    2 Windows资源监控中,如果System\Processor Queue Length大于2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

——能否具体说说为什么这种情况说明存在处理器阻塞?

——在Unix/linux 操作系统,当CPU利用率低,但是事务响应时间仍然较长时,还需要观察 I/O Wait 的变化,以鉴别是否因为 I/O 导致 CPU 利用率低;


非常感谢楼主总结自己的经验来与大家分享 ^_^
作者: cgoods    时间: 2006-2-17 17:03
相当不错
作者: luxuabc    时间: 2006-2-17 17:21
不错
作者: jessie-hu    时间: 2006-2-20 17:15
受益匪浅啊,谢谢楼主!
作者: ciwei    时间: 2006-2-21 17:57
非常感谢楼主啊,正在找这方面的东西,楼主就发上来了,真是雪中送炭啊!
再请问一下楼主,UNIX资源监控中指标内存页交换速率(Paging rate),这个值一般为多少认为正常呢???
超过什么范围认为高呢???
作者: FlySpace    时间: 2006-2-22 01:29
great
作者: alexchen    时间: 2006-2-22 09:54
谢谢楼主!
作者: john_c_cooper    时间: 2006-3-16 11:42
just so so
作者: wisebinbin    时间: 2006-3-16 13:38
拷下来了,谢谢了先
作者: 可乐+冰    时间: 2006-3-21 16:59
非常感谢!
作者: elisly    时间: 2006-3-22 11:29
谢谢楼主了!!!希望以后能分享更多宝贵经验。。。。。。
作者: sunfy    时间: 2006-3-24 11:17
正在学习性能分析阶段!感谢!
作者: test51testing    时间: 2006-3-24 13:36
多谢搂住!
作者: 小灰尘    时间: 2006-3-27 12:20
。。。。。。真的是这样么?!!!怀疑ing.^_^
我一直以来从事压力测试想法都和你写的一样,但是最近好像感觉似乎这样测试是不正确的.
我把我的想法写一下大家看看是不是有什么地方不对。;P

测试目的:
我们做的是软件测试,测试的对象应该是软件.但是现在这种测试方法却把硬件资源也加入到软件测试之中了.并且以硬件资源的占用来衡量软件性能.似乎是走到了一个误区.后面我会举异步处理的例子。

测试方法:
分段排除法我认为可以理解。但是服务器硬件瓶颈是在第一轮就已排除了,怎么可以用到后面对软件性能的评估当中?也就是说一楼帖子中的“分析信息来源”中的服务器cpu men io 等资源占用情况的数据分析是否还属于软件性能测试的有效数据依据。

当并发数的测试遇到异步处理:
并发概念在遇到异步处理机制时似乎被完全颠覆了,异步处理机制的目的本身就是为了优化大并发量时server的处理性能。因此在给异步处理机制的系统做压力的时候系统资源占用数据变化极小,并且在高并发数压力下同样能处理正常而不占用大量资源。此时对server资源的监控已经基本失去意义。而且与此同时并发数也失去实际意义--压20和压2w对server来说无明显变化,如何判断支持最大并发数是多少呢?

工具真的能压出软件的真实性能么?
引用牛人的一句话:性能瓶颈不是靠工具测试出来的,而是开发和测试人员一起分析出来的.

吃饭先了 呵呵

[ 本帖最后由 小灰尘 于 2006-3-28 15:58 编辑 ]
作者: 小灰尘    时间: 2006-3-27 14:48
我是ash 呵呵

[ 本帖最后由 小灰尘 于 2006-3-28 15:58 编辑 ]
作者: 笑游天涯侠    时间: 2006-3-27 18:11
标题: to PCL(pcl = ash ?)
老兄的想法和认识都很好。
但对你想法,我谈谈自己的看法:
        我们是作软件测试,但软件是运行在硬件上的一种载体,如果剥离硬件、网络,单谈软件的性能,有点虚。所以我个人认为,性能测试(并发负载压力)的对象不仅仅只是软件,应该是整个系统,包括软件、硬件和网络。
        由于我们无法知道软件的性能如何,所以我们只能依靠硬件、网络的一些计数器和响应时间来体现,通过这些计数器来进一步分析问题所在。站在测试人员的本质工作的角度上讲,我也认为我们作性能测试应该尽量去发现软件中的问题,对软件进行调优。但调优的工作难度、工作量都很大,我们不可能一遍遍的去作,所以只能以制定的性能指标为衡量需不需要调优的标准。
        对异步处理机制的系统,由于其处理方式已不同,所以当然不能用客户端的并发用户数来衡量其性能,其性能指标我认为应该按照吞吐量(每秒的处理事务数)来衡量。
       “性能瓶颈不是靠工具测试出来的,而是开发和测试人员一起分析出来的.” 我非常赞同这句话,但如果没有测试工具执行的测试结果,那我们只能一句句地去分析代码。工具不是万能的,但没有工具也是很难的
作者: 笑游天涯侠    时间: 2006-3-28 10:14
标题: 补充
性能测试的目的有多种:
         1 考察系统是否满足预期的性能要求;
         2 考察系统的可扩展性;
         3 作为对系统进行调优的参考;
         4 用性能测试手段发现系统存在的问题;
         5 提供部署方案的参考。
所以,并不是所有的性能测试都要去发现软件存在的问题或对其调优。
        并发用户数、业务操作的响应时间、服务器的资源监控指标及吞吐量等数据只是常用的性能分析的数据指标,但并不说都需要对这些指标进行分析,而是要根据应用系统的处理方式等特点来制定具体的、适合本系统的性能指标。
       性能测试(并发负载压力)是尽量去模拟真实环境下系统的性能表现,肯定很难完全到达与真实环境下的一摸一样,它们间的差异大小取决于我们制定的性能测试方案。
作者: 小灰尘    时间: 2006-3-28 12:19
我遇到过一个测试纯软件性能的团队。他们有很特殊的想法,他们依靠纯软件性能数据的分析把整体软件性能评估的非常深刻及完整。确实让我惊讶了一番。我正在学习这种分析方法,有了思想成果我会抽时间整理一下贴到坛子里给大家分享一下。
先摘抄他们的一句话给大家:不要期望依靠性能测试节省机器,因为机器本身只要2、3w,对大型项目来说根本没有意义,但是人力资源成本就已经远远超过这几w块了。我们一定要i认清楚到底是为了什么在做测试。

                                                                                                                                                       ---ash
作者: ni_xh    时间: 2006-3-28 13:25
收藏了
作者: bjlwt2000    时间: 2006-5-31 16:15
对于分析有很大帮助!
作者: cathycyl    时间: 2006-7-4 15:11
Thank you ,LZ!!
作者: fish_yy    时间: 2006-7-4 16:59
写的不错
作者: j_east    时间: 2006-7-7 20:03
收藏收藏,呵呵
作者: oscarli    时间: 2006-7-20 15:20
标题: 好东东就要顶
好东东,
作者: zhmiss    时间: 2007-6-20 15:14
现在就是对结果分析这块很迷茫了,谢谢了!
作者: kiting2006    时间: 2007-6-20 16:33
好文章,收藏了,谢谢楼主
作者: suoyi    时间: 2007-6-20 17:19
谢谢楼主分享~~sdlkfj2
好像有人拿类似内容的帖子卖钱呐~~
作者: stevenhappy    时间: 2007-6-20 18:46
强,说的很有道理!向你学习!
作者: hanghong_good    时间: 2007-6-21 10:01
定。。。。
作者: wslo888    时间: 2007-6-21 10:09
相见恨晚
作者: Graceli    时间: 2007-7-25 13:35
强烈支持sdlkfj5
作者: lewis2555    时间: 2007-7-27 16:37
路过  不错
作者: dbg1314    时间: 2007-7-30 09:28
收藏了。。。。
作者: gary198026    时间: 2007-7-30 14:20
good 不错
作者: 1qazse4    时间: 2007-9-17 12:03
顶,学习了!~!
作者: 3155530    时间: 2007-9-21 16:23
再顶一顶,哈哈,不错,学的蛮多
作者: Jon    时间: 2007-9-21 16:33
兄弟 写的不错,顶
真的,做为我们,应该多问问自己,
What是性能测试,Why要进行性能测试,Where进行性能测试,When进行性能测试,How进行性能测试......
作者: xugaoxiang    时间: 2007-9-24 16:59
so good
作者: fyyesp    时间: 2007-10-9 13:02
不错~~
非常感谢!
作者: cuizhihui    时间: 2007-10-9 13:47
标题: 不错~~~~
学习中....
作者: hankliu520    时间: 2007-10-11 16:19
学习、研究中。
作者: yxt168118    时间: 2007-10-11 17:54
1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%


想问一下大虾,这个cpu占用率与unix的topas命令获取的同一个cpu的占用率有什么不同?为何同一时刻,同一个cpu的两个值不一样?多谢多谢!!
作者: mtang008    时间: 2007-10-16 11:39
非常感谢楼主
作者: hbxtly    时间: 2007-10-16 12:18
太强了,学习这种总结能力
作者: hibetty    时间: 2007-10-31 12:02
标题: 回复 1# 的帖子
Wonderful!Thanks for sharing。
作者: junfei521    时间: 2007-10-31 13:57
值得一看,学习ing

作者: cangmang    时间: 2007-11-12 13:03
刚开始上手LR,对跑完脚本后生成的数据一直感觉到无从下手,感谢楼主拉!
作者: wpwpwpw8685    时间: 2007-12-10 21:26
标题: 谢谢
谢谢
作者: meng0819    时间: 2007-12-15 11:55
都是高人!!
高人还是很多的!
作者: askyfree    时间: 2007-12-17 09:33
写的不错,多谢楼主
作者: askyfree    时间: 2007-12-17 10:02
十分期待66楼的大作
作者: thloong    时间: 2007-12-17 17:32
我真的顶了
作者: pangda    时间: 2007-12-17 17:37
接力
作者: jhui008    时间: 2008-2-13 18:23
标题: 好帖,总结的非常好
好帖,总结的非常好。希望越来越多的高手都有这样的分享精神。谢谢
作者: lchlucia    时间: 2008-3-4 16:35
挺好的!
作者: suiyingliunian    时间: 2008-5-7 10:42
真的很有用,谢谢了!
作者: saturnman    时间: 2008-5-8 13:52
学习!
作者: 小狐狸如如    时间: 2008-5-8 13:56
难得的好贴
作者: humeihappy2000    时间: 2008-5-8 16:06
正是我要学习的地方,太好了。万分感谢
作者: anata    时间: 2008-5-9 16:14
好贴,学习中.....
作者: gcg07    时间: 2008-7-11 16:12
谢谢分享 期待更好的东西
作者: carry1986    时间: 2008-7-14 16:05
支持原创,学习,没有亲手实践现在很难学会呀!!!!!!!!!!
作者: lantianwei    时间: 2008-7-14 22:31
PEFECT!
作者: 随意    时间: 2008-7-16 17:20
真的很有用,我都做笔记了,谢谢lz哈
作者: goodgoodsutdy    时间: 2008-7-22 16:35
值得收藏
作者: 燕子东南飞    时间: 2008-7-26 11:40
真的值得学习了,很经典
作者: wingshen    时间: 2008-7-26 13:38
谢谢分享
作者: powerpopo    时间: 2008-8-22 12:03
标题: hehe
see  1  see   ,study  study.^_^
作者: wdzawc    时间: 2008-8-24 09:46
LZ授教了
作者: gz_xie    时间: 2008-12-13 16:13
学习中。
作者: guotufu    时间: 2008-12-17 11:06
gggggoooooooooooddddd!
作者: kelly6772    时间: 2008-12-17 14:06
写的不错,下次可不可以举例说明啊,谢谢
作者: 欧阳    时间: 2008-12-17 15:51
顶,相当感谢
作者: 欧阳    时间: 2008-12-17 15:55
感谢
作者: yetties2005    时间: 2008-12-17 17:59
写的真的不错哦。。。
作者: belie    时间: 2009-2-18 16:26
感谢分享!~




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