性能测试结果分析

1、性能测试工程师根本上都能够掌握利用测试工具来作负载、 压力测试， 但多数人对怎样去分 析工具收集到的测试结果感到无从下手， 下面我就把个人工作中的体会和收集到的有关资料 整理出来，希望能对大家分析测试结果有所帮助。 分析原那么：1. 具体问题具体分析这是由于不同的应用系统，不同的测试目的，不同的性能关注点2. 查找瓶颈时按以下顺序，由易到难。效劳器硬件瓶颈 -网络瓶颈对局域网，可以不考虑-效劳器操作系统瓶颈参数配置 -中间件瓶颈参数配置，数据库， web 效劳器等 -应用瓶颈 SQL 语句、数据 库设计、业务逻辑、算法等注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度

2、。 对一些要求低的，我们分析到应用系统在将来大的负载压力并发用户数、数据量下，系 统的硬件瓶颈在哪儿就够了。3 分段排除法 很有效分析的信息来源：1 根据场景运行过程中的错误提示信息2 根据测试结果收集到的监控指标数据一错误提示分析分析实例：1 Error: Failed to connect to server “ .30:8080" : 10060 Conn ectionError: timed out Error: Server “ .30" has shut dow n the connection prematurely分析：A 、应用效劳死掉。小用户时：程序上的

3、问题。程序上处理数据库的问题B、应用效劳没有死应用效劳参数设置问题例：在许多客户端连接 Weblogic 应用效劳器被拒绝，而在效劳器端没有错误显示，那么 有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低。如果连接时收到 connection refused 消息，说明应提高该值，每次增加25C、数据库的连接(1、在应用效劳的性能参数可能太小了2、数据库启动的最大连接数 跟硬件的内存有关 )2 Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成A 、应用效劳参数

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

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

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

7、U 占用率 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)过高的用户占

8、用 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页面读取操作速

9、率很低，那么可能存在磁盘瓶径。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) 太长

10、的运行进程队列，但 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 R

11、equests/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= 'fre

12、e 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_B

13、UFFER 参数的值。 日志缓冲区的申请情况 ：select name,value from v$sysstat where name = redo log space requests4 如果内存排序命中率小于 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 b

14、.name= ' sorts (memory) '注：上述 SQL Server 和 Oracle 数据库分析，只是一些简单、根本的分析，特别是 Oracle 数 据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比拟复杂、需要具备很多相关的专业知识， 因此常常会感觉拿到数据不知从何下手。 这也是我学习 性能测试过程中感觉比拟为难和棘手的事，为此我在研读了? WEB 性能测试实战?后特作了以 下笔记，这里只是书中第 4 章 WEB 应用程序性能分析的一局部，贴出来希望和大家共同讨论：性能分析的根

15、底知识：TPS每秒钟处理的交易数、点1. 几个重要的性能指标：相应时间、吞吐量、吞吐率、击率等。2. 系统的瓶颈分为两类：网络的和效劳器的。效劳器瓶颈主要涉及：应用程序、WEB 效劳器、数据库效劳器、操作系统四个方面。3. 常规、粗略的性能分析方法：当增大系统的压力或增加并发用户数时，吞吐率和TPS的变化曲线呈大体一致，那么系统根本稳定； 假设压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很 可能是网络出现带宽瓶颈，同理假设点击率 /TPS 曲线出现变化缓慢或者平坦，说明效劳器开始出 现颈。4. 作者提出了如下的性能分析根本原那么，此原那么本人十分赞同：由外而内、由表及里、层

16、层深入应用此原那么，分析步骤具体可以分为以下三步： 第一步：将得到的响应时间和用户对性能的期望值比拟确定是否存在瓶颈；第二步：比拟Tn网络响应时间和 Ts效劳器响应时间可以确定瓶颈发生在网络还 是服务器；第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。以 WEB 应用程序为例来看下具体的分析方法：1.用户事务分析：a. 事务综述图(Transaction Summary ):以柱状图的形式表现了用户事务执行的成功与失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。 假设失败的事务非常 多，那么说明系统发生了瓶颈或者程序在执行过程中发生了问题。b. 事务平

17、均响应时间分析图 Average Transaction Response Time：该图显示在测试场景运行期间的每一秒内事务执行所用的平均时间， 还显示了测试场景运行时间内各个 事务的最大值、 最小值和平均值。 通过它可以分析系统的性能走向。 假设所有事务响应时间根本 成一条曲线， 那么说明系统性能根本稳定； 否那么如果平均事务响应时间逐渐变慢， 说明性能有下降趋 势，造成性能下降的原因有可能是由于内存泄漏导致。c. 每秒通过事务数分析图Transaction per Second即TPS：显示在场景运行的每一秒中，每个事 务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事

18、务负载。 假设随着测试的进展， 应用系统在单位时间内通过的事务数目在减少， 那么说明效劳器 出现瓶颈。d. 每秒通过事务总数分析图 Total Transactions per Second：显示场景运行的每一秒中，通过、失败以及停止的事务总数。假设在同等压力下，曲线接近直线，那么性能基 本趋于稳定； 假设在单位时间内通过的事务总量越来越少， 即整体性能下降。 原因可能是内存泄漏 或者程序中的缺陷。e. 事务性能摘要图Transaction Performanee Summary：显示方案中所有事务的最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求重点关注事务平均、 最大执行时间。

19、f. 事务响应时间与负载分析图Transaction Response Time Under load:通过该图可以看出在任一时间点事务响应时间与用户数目的关系， 从而掌握系统在用户并发方面 的性能数据。g. 事务响应时间百分比图Transaction Response Time(percentile):该图是根据测试结果进行分析而得到的综合分析图。 分析该图应从整体出发， 假设可能事务的 最大响应时间很长，但如果大多数事务具有可接受的响应时间，那么系统的性能是符合。h. 事务响应时间分布情况图Transaction Response Time (Distribution):该图显示了测试过程

20、中不同响应时间的事务数量。 假设系统预先定义了相关事务可以接受的最 小和最大事务响应时间，那么可以使用此图确定系统性能是否在接受范围内。分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入的分析。没有贴图，看起来有点费力，如果你对这些图都比拟了解，应该是比拟简单的分析原那么：? 具体问题具体分析这是由于不同的应用系统，不同的测试目的，不同的性能关注点? 查找瓶颈时按以下顺序，由易到难。效劳器硬件瓶颈 -网络瓶颈对局域网，可以不考虑-效劳器操作系统瓶颈参数配置-中间件瓶颈参数配置，数据库，web效劳器等-应用瓶颈SQL语句、数据库设计、业务逻辑、算法等 注：以上过程并不是每个

21、分析中都需要的， 要根据测试目的和要求来确定分析的深度。 对一 些要求低的，我们分析到应用系统在将来大的负载压力并发用户数、数据量下，系统的 硬件瓶颈在哪儿就够了。? 分段排除法 很有效 分析的信息来源：?1 根据场景运行过程中的错误提示信息?2 根据测试结果收集到的监控指标数据 一错误提示分析分析实例：1 ?Error: Failed to connect to server“ paymer0b6(heConnection?Error: timed out Error: Server“ uSer.baihehut down the connection prematurely分析：?A、应用

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

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

24、况和业务操作响应时间进一步分析原因所在。2业务操作响应时间：? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用 “事务性能摘 要图，可以确定在方案执行期间响应时间过长的事务。? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起 的？问题是否与网络或效劳器有关？? 如果效劳器耗时过长， 请使用相应的效劳器图确定有问题的效劳器度量并查明效劳器性能 下降的原因。如果网络耗时过长，请使用 “网络监视器 图确定导致性能瓶颈的网络问题2-5-10 原那么：简单说，就是当用户能够在 2 秒以内得到响应时，会感觉系统的响应很快；当 用户在 2-5 秒之间得到响应时

25、，会感觉系统的响应速度还可以；当用户在5-10 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个 Web 站点， 或者发起第二次请求3效劳器资源监控指标：内存：1 UNIX 资源监控中指标内存页交换速率Paging rate ，如果该值偶尔走高，说明当时有线程竞争内存。如果持续很高，那么内存可能是瓶颈。也可能是内存访问命中率低。2 Windows 资源监控中， 如果 ProcessPrivate Bytes 计数器和 ProcessWorking Set 计数器的值 在长时间内持续

26、升高，同时 MemoryAvailable bytes 计数器的值持续降低，那么很可能存在内 存泄漏。内存资源成为系统性能的瓶颈的征兆 :很高的换页率 (high pageout rate);进程进入不活动状态 ; 交换区所有磁盘的活动次数可高 ;可高的全局系统 CPU 利用率 ;内存不够出错 (out of memory errors)处理器：1 UNIX 资源监控 Windows 操作系统同理中指标 CPU 占用率 CPU utilization ，如果该值持续超过95%，说明瓶颈是 CPU。可以考虑增加一个处理器或换一个更快的处理器。如果效劳器专用于 SQL Server,可接受的最大上

27、限是 80-85%合理使用的范围在 60%至 70%。2 Windows 资源监控中，如果 SystemProcessor 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 Tim