性能测试分析篇

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

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

3、t (120 seconds) has expired 分析：可能是以下原因造成A、应用服务参数设置太大导致服务器的瓶颈B、页面中图片太多C、在程序处理表的时候检查字段太大多二监控指标数据分析1最大并发用户数：应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置）下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那

4、么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。2业务操作响应时间： 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？ 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题3服务器资源监控指标：内存： 1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶

5、尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。 2 Windows资源监控中，如果ProcessPrivate Bytes计数器和ProcessWorking Set计数器的值在长时间内持续升高，同时MemoryAvailable bytes计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆: 很高的换页率(high pageout rate); 进程进入不活动状态; 交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率; 内存不够出错(out of memory errors) 处理器： 1 UNIX资源监控（Wind

6、ows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。 2 Windows资源监控中，如果SystemProcessor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time) CPU空闲时间为零(zero percent idle CPU) 过

7、高的用户占用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页面读取操作速率很低，则可能存

8、在磁盘瓶径。 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却空闲

9、(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(锁请求/

10、秒)，通过优化查询来减少读取次数，可以减少该计数器的值。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 如果数据的缓存命中率小

11、于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 wher

12、e 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 =sorts (disk) and =sorts (memory) 注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数

13、据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。说明： 以上只是个人的体会和部分资料的整理，并不代表专家之言。算抛砖引玉，有不同看法和更深入的分析的，希望大家勇要发言，以推动我们国内的性能测试工作。什么是软件性能首先澄清的第一个概念是什么是软件性能，作者分别从用户视角，管理员视角和开发人员的视角列出下面的问题，这些就是所谓的软件性能。你有过其中的疑问就是在考虑软件性能的范畴了，寻求解决方案的过程及其结论(report)就是软件性能测试1. 用户所体会到的系统响应时间是否够快?2. 应用服务器的资源使用情况是否合理？3. 数据库服务器的资源使用情况是否合理？4. 系统能最多支持多少

14、用户的访问？最大的业务处理量是多少?5. 系统是否支持 7*24小时的业务访问？6. 系统是否能够实现扩展？更换那些设备可以提高系统性能？7. 系统的架构设计是否合理？8. 数据库设计是否合理？9. 代码是否存在性能问题？10. 内存使用是否合理？11. 线程同步是否合理？12. 资源竞争是否合理？13. 如果存在性能瓶颈，应该如何调整？几个主要术语1. 响应时间 : 响应时间分解为 网络传输时间， 应用延迟时间，数据库延迟时间，呈现时间。对响应时间的分解是为了方便定位性能瓶颈的所在。2. 并发用户数 : 并发用户数一定要区别于同时在线用户数。在我们进行测试计划和测试目标的阶段通常会有明确的系

15、统用户数和同时在线人数的参考依据，但并发用户数是不确定的。并发是针对某一个或某几个业务的行为，所以并发用户数取决于用户的行为即业务模式。所以确定用户的行为建立真实的模拟业务场景在性能测试中尤为重要。3. 吞吐量 : 单位时间内系统处理的客户请求的数量。 通常以请求数/秒或者页面数/秒衡量软件性能测试方法论1. SEI Load Testing Planning Process: 是一个关注于负载测试计划的方法，目标是产生 “清晰，易理解，可验证的负载测试计划”. 区别生产环境和测试环境的不同，分析用户的行为以产生用户和用户场景.2. RBI (Rapid Bottleneck Identify

16、) : 是 Empirix 公司提出的快速识别系统性能瓶颈的方法。首先确定是由并发还是吞吐量引发的性能瓶颈，通过不断增加并发用户数和吞吐量观察系统的性能表现，然后从网络，数据库，应用服务器和代码本身4个环节确定系统性能的瓶颈。3. 性能下降曲线分析法: 分析随着用户数增长响应时间或吞吐量下降的曲线，通过定位性能拐点找到性能瓶颈产生的地方.4. Load Runner 性能测试过程 : 计划测试-测试设计-创建VU脚本-创建测试场景-运行测试场景-分析结果5. Segue 性能测试过程: 从确定性能基线开始，通过单用户访问获取性能取值基线，然后设定可接受的性能目标，用不同的并发用户数进行 Try

17、-Check的重复测试. 软件性能测试分类 1. 性能测试 : Performance Testing 这是一个容易混淆的概念，通常泛指所有的性能测试。本文特指在特定条件下验证性能是否达到预期指标的测试为性能测试。2. 负载测试 : Load Testing 是指模拟真实的用户行为，通过不断加压直到性能出现瓶颈或资源达到饱和。负载测试是我们最经常进行的性能测试，用于测量系统的容量，发现系统瓶颈并配合性能调优。有时候也称为可量性测试 Scalability Testing.3. 压力测试 : Stress Testing 是指测试系统在一定的饱和状态下系统的处理能力。负载测试的不断加压到一定阶段

18、即是压力测试，两者没有明确的界限。压力测试通常设定到CPU使用率达到75%以上，内存使用率达到 70%以上，用于测试系统在压力环境下的稳定性。此处是指过载情况下的稳定性，略微不同于7*24长时间运行的稳定性。4. 可靠性测试 : Reliability Testing 是指加载一定的业务压力，同时让此压力持续运行一段时间，测试系统是否可以稳定运行. 可以理解为压力测试关注的是过载压力，可靠性测试关注的是持续时间。5. 并发测试 : Concurrency Testing 是模拟用户并发访问同一应用的测试，用于发现并发问题诸如内存泄漏，线程锁，资源争用，数据库死锁。6. 配置测试 : Confi

19、guration Testing 验证各种软,硬件配置对系统性能的影响，用于性能调优和规划能力.7. 失效恢复测试 : Failover Testing 针对有冗余备份和负载均衡的系统，检验系统局部故障时用户所受到的影响.本文来自CSDN博客，转载请标明出处：这几天碰到这么几件事情，觉得挺有意思的：1. 有个朋友问了我一个问题：LoadRunner的缺点在哪？然后我反问她：LoadRunner的优点在哪？她一时语塞，后来说：感觉都是优点没有什么缺点呀？2. 一个网友跟我说：我觉得会用LoadRunner的人很强。我说：LoadRunner只是一个工具，并且功能也很有限。对于大部分测试人员来说，

20、学习从工具入手都不是坏事，但是过于在意工具肯定是件坏事，也许我们经常从工作几年人的嘴里听说过这样的话：工具仅仅是工具而已，主要是思路。这种话让我们有种忽悠的感觉。下面正面谈一下LoadRunner。1. LoadRunner 阻碍了性能测试人员对通信过程的理解我希望做性能测试的人能忘掉这个工具。我们都知道VuGen有录制的功能，其实录制这个功能对于测试来说是个非常不好的选择，就是跟后面的场景执行带来很多的不定的因素。因为一些人对脚本的不理解，或者说根本就不知道脚本是什么意思，导致了出现一些性能问题的时候，束手无策。也不知道如何去查找原因。所以我觉得性能测试人员手写脚本是最好的选择，但是难道录制

21、功能就不可用吗？当然不是这样，不过如果录，就一定要知道脚本中各个函数的含义，要彻底明白这些函数想完成什么功能，能实现什么，不能实现什么。这样才能在出现某些问题时，知道如何去解决。并且问题的解决过程要依赖其他的知识，并不是会了LR，找了帮助，就可以解决得了的。所以依赖工具要有个度，不然做的性能测试也不可信。我们都知道LR支持了很多网络协议，并且根据这些具体网络协议衍生出各自的专用语言，这个应该是它最大的优点了，但是LR也并不是对这些它声明了支持的语言都支持的很好的。我们知道在8.0版本的时候，LR里面就已经有了Java ajax的协议，但是如果不修改配置文件是不显示出来的。那到现在9.5的版本，

22、早已经把这个协议公开出来了，但是用这个协议还是感觉遇到很多这样那样的问题。同样，其他有些协议也是这样。会用工具，和会做性能测试，绝对是两回事，所以不要太依赖LR。我们都知道Mercury提出了BTO的概念，所以很多LR里的概念设计也是从business的角度来解释的。做测试的专业人员，要了解它的这些概念和我们具体的环境之间的关系，否则只能照搬照套。所以也可以这么说，LR的重点在于对协议的掌握程度，不一定都会，但是要特别精通某些一些跟自己测试密切相关的。其实我们的测试人员很多都不太了解上述的 ajax架构，所以即使做了性能测试也是“止于外表，不及其里”，那么就浪费资源了。再说一点，LR对数据库的

23、支持。一直以来，我们知道，在LR里要想直接面对数据库测试，是比较麻烦的（相对http协议来说）。前几天，看了一下其他的工具，有些工具中把和数据库通信做成了相应的模块，操作起来，很简单，需要编写的代码也比较少。这样的功能就比LR中做的要好。但是我们也要理解，LR是 BTO概念下的产品。值得注意的是，开发很多都会用到类映射数据的模式进行相应表操作（例如hibernate），这样在性能测试的时候需要特别注意对应用服务器的进程设置，也许会出现这样的场景，数据库服务器无压力，应用服务器已经提前“阵亡”了。2. LoadRunner简化了性能测试过程从Mercury的性能测试执行流中可以看到，它分成了这么

24、几个部分：计划测试、创建脚本、创建场景、执行场景、分析结果。这种分法，可以说代表了性能测试过程中的主要部分。但是这个过程也会导致结果混乱。首先，性能测试需要调研，并且需要调研的很细，可能在大部分的公司里都没有做到这样，但是，这不能说明调研这部分是可以忽略的。我们经常会遇到性能测试做完了，还在讨论性能测试需求的现象。这对于我们来说不能不说是难受的事情。还有建模，LR的方法论和执行流中都没有提到建模这一过程，而在实际的应用环境中，我们还是要考虑这一过程，只有这一过程才是场景设置的前提。应该说，在LR中做不到建模，但是应该在执行流和方法论中提到它。在一个完整的性能测试过程中，还有很多的管理上的因素制

25、约，当然，这个不能依赖工具。我们后面再谈相关的问题。在LR的市场如此强大之下，我觉得应该只考虑到它是一个工具，而不是可以完成性能测试整个过程中的事情的万能产品。我在遇到很多初学性能测试和已经做过一段时间的性能测试的朋友，经常被问到类似这样的一些问题：我会用LR了，我可以做性能测试了？我们公司有LR了，我们可以推广性能测试了吗？或者更严重的，有了LR，性能测试就有了保障的感觉。它并不是尚方宝剑，我们拿了谁都能砍。实际上，知道如何砍或者怎么砍才是最重要的，竹叶也是利器。我碰到过好几次这样的现象，客户认为给了两天的时间或者一天时间就可以把一个性能测试做完了，因为你用的是工具，并且它又能自动生成结果。

26、而往往，一个非常非常熟悉工具的人，对过程和结果的分析都不是很清楚。并且写报告时也只能描述表面的现象。这样的性能测试只能说有个警示的作用，对实际的系统质量提升意义都不大。有一个80年代就开始写程序的同事说：“这种性能测试方式，对系统质量一点都起不到保障作用，只是忽悠客户。”并且系统级别的性能测试已经不可能从大局上去改变什么了，只能寻找一下系统的缺陷，也谈不到对调优有什么建设性的指导意义。而LR的设计主要还是面对系统级的性能测试，所以我们使用它，要了解它能给我们带来什么。也许有人要钻牛角尖，我就用它来做更细的代码和集成的性能测试不可以吗？也不能说完全不能，用牛刀杀鸡也是行的，就是挥着过重，搞不好鸡

27、没杀好反而平添肩周炎。3. LoadRunner的监控弱点前几天被问到LR对数据库和应用服务器的监控问题，我一直在建议他们用其他的工具去做。因为LR的监控只是一个壳子，并且个人认为，是个效率不是很高的壳子。就拿对oracle的监控来说，我们都知道LR在连接了oracle之后，会有两个表可以选择，里面有很多的计数器，对性能测试工程师来说，选择什么计数器，都是很为难的事情，因为不知道这些计数器是什么意思。所以大部分情况下，我们看到一些人的推荐就是选择默认的那些（在help里有一些说明）。如果我们遇到的问题正好在我们选择的那几个计数器里有体现，还真是太幸运了。不过这种现象就像走在路上捡了一百块钱一样

28、不稳定。所以我们还要反复的去执行场景以判断问题出现的瓶颈。这对我们性能测试来说是很痛苦的事情。因为有些场景可以执行了好几个小时，好几天，甚至一周时间。监控Weblogic也是一样，我宁可肯定用WebLogic Scripting Tool去写脚本监控，也不是很推荐用LR的监控功能。就算排除工具之间的兼容性不说，我觉得LR做到的监控也比性能测试过程中想达到的效率要差不少。当然，有些商业工具已经做的相当好了，并且资源占用还可以接受。对unix的监控也是这样，我们如果用LR来做，可能不知道什么时候，RPC就倒塌了。我们不得不重头再来，这一点对我们长时间的场景执行来说，都是致命的伤害。用LR监控uni

29、x，尽量的可不用就不用。用nmon或者使用UNIX自带的性能监视工具都可，什么top啊glance啊有的咱们都上，不过最后提醒一句，它们的运行也都是需要申请主机资源的。因为很多人喜欢在一个结果里看到所有的数据，目的是为了保证数据的同步性，所以不遗余力的在LR中完成这样那样的监控功能。但是不管数据在结果中有多全，对结果的分析还是要靠自己敏锐的嗅觉和丰富的经验，并且，LR中实现的这样的监控点其实效率并不高，所以我推荐的是，用最少的资源做最多的事情。不要太依赖某个工具。我现在的工作中，做一次完整的性能测试，都会用到很多个工具，组合这些工具的结果，一起分析。并且有些功能的实时查看功能要比LR强很多。再

30、加上，LR的结果直接生成的报告，也不可能做为我们的最终报告来用，所以让所有的数据都在分析器里的做法，只具有无意义的个人完善感，对实际的结果意义不大。4. LR是个前端工具（这里说的前端工具，不是指页面的展现，而是为了强调在一个应用中LR工具所在的位置）通常情况下，在LR中能够体现出来的问题，已经是经过了系统中一系列的处理之后抛到LR上的，所以，我们再讨论LR的某个错误代号和打印出来的那一串串红色的字符串已经没有实质的意义了。还需要进一步去分析应用的整个通信过程，才能找到最终问题本质。例如某些程序员喜欢把原始SQL语句直接写到代码中，几百万行你哪里找得到？性能出来了就很难看， LR肯定会告诉你机

31、器IO吞吐的厉害，再细分原因就啥都没有了，与其这样还不如自己写性能分析器呢。就像昨天刚给一个朋友解决的一个思考时间放到for循环内部和外部就出现不同的错误一样，如果仅仅看LR，肯定只能描述这个问题的现象，而找不到问题的原因。在LR的场景执行过程中，所有的默认获取的数据，都是从LR这个工具本身得到的，也就是说这些数据，都不能直接反应服务器的性能状况。我们分析这些数据的时候，一定要给出相应的服务器端的数据，以证明我们的这个数据是有意义的。单独说TPS有多少，响应时间有多大，吞吐量有多高，一点意义都没有。因为这些数据是有前提的，而这些前提，LR都提供不了。当然，所有的压力产生的工具，也都是前端工具。

32、把它单独拎出来说的原因是要说明，性能测试并不是一个前端工具，可以做得完的。它只能是一个承载现象的工具。真正要做的还是后面的分析。5. 关于分析和调优在分析这一块，analysis还是给出了不少好用的工具的，当然这些工具对数据的处理，也是有一定的原因和规律的。我们还要了解到这些，才能对一个结果做非常完善的分析。就拿一个简单的例子来说，LR中提供的响应时间在summary里为什么是最大、最小、平均、标准方差、90%这几个值？我们要了解这些的原因，再去做详细的分析，从而可以完善的对前端的数据做分析了。但是这些分析，都不能成为报告中的关键数据，因为还需要对一个系统的所有层面做分析才能在报告中写上有建议

33、性意义的部分。我们做性能测试，不能说，可能是什么原因引起了什么问题，我经常看到这样的报告。这样的报告，如果是写给我看的话，我肯定是打回去重写。我们面对客户的时候，也会出现这样的问题，前一阵子刚做了一个项目，另一个同事写的报告，就让我从头到尾的改了一遍，因为原来的报告中只是数据的罗列。相对来说，LR在罗列数据这一块，做的还是最好的。但是，LR不会告诉你你测试的结果怎么样，当然你可以设置SLA，但是也没有什么用，因为这个设置是在你知道你的目标的前提下，这里仅是拿SLA和测试结果做个对比，以供写报告时好看而已。当然分析数据中包括DB、APP、Middleware等等的数据时，我们还要查看相应的监控结果。分析是一个顺藤摸瓜的过程，千万不能断，断了