2022年性能测试结果分析 .pdf
性能测试工程师基本上都能够掌握利用测试工具来作负载、压力测试， 但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。分析原则：1. 具体问题具体分析这是由于不同的应用系统，不同的测试目的，不同的性能关注点2. 查找瓶颈时按以下顺序，由易到难。服务器硬件瓶颈-网络瓶颈对局域网，可以不考虑-服务器操作系统瓶颈参数配置 -中间件瓶颈参数配置，数据库，web 服务器等 -应用瓶颈SQL 语句、数据库设计、业务逻辑、算法等注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力并发用户数、数据量下，系统的硬件瓶颈在哪儿就够了。3 分段排除法很有效分析的信息来源：1 根据场景运行过程中的错误提示信息2 根据测试结果收集到的监控指标数据一错误提示分析分析实例：1 Error: Failed to connect to server “.30:8080: 10060 Connection Error: timed out Error: Server “.30 has shut down the connection prematurely 分析：A、应用服务死掉。小用户时：程序上的问题。程序上处理数据库的问题B、应用服务没有死应用服务参数设置问题例：在许多客户端连接Weblogic 应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic 中的server 元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused 消息，说明应提高该值，每次增加25C、数据库的连接(1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数跟硬件的内存有关) 2 Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成A、应用服务参数设置太大导致服务器的瓶颈精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 1 页，共 10 页B、页面中图片太多C、在程序处理表的时候检查字段太大多二监控指标数据分析1最大并发用户数：应用系统在当前环境硬件环境、网络环境、软件环境参数配置下能承受的最大并发用户数。在方案运行中，如果出现了大于3 个用户的业务操作失败，或出现了服务器shutdown 的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也到达了用户要求，那么OK 。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。2业务操作响应时间：分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题3服务器资源监控指标：内存：1 UNIX 资源监控中指标内存页交换速率Paging rate ，如果该值偶尔走高，说明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。2 Windows 资源监控中， 如果 ProcessPrivate Bytes 计数器和ProcessWorking Set 计数器的值在长时间内持续升高，同时MemoryAvailable bytes 计数器的值持续降低，则很可能存在内存泄漏。内存资源成为系统性能的瓶颈的征兆: 很高的换页率 (high pageout rate); 进程进入不活动状态; 交换区所有磁盘的活动次数可高; 可高的全局系统CPU 利用率 ; 内存不够出错 (out of memory errors) 处理器：精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 2 页，共 10 页1 UNIX 资源监控 Windows 操作系统同理中指标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) 过高的用户占用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; 精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 3 页，共 10 页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 数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。性能测试的结果分析是性能测试的重中之重。在实际工作中，由于测试的结果分析比较复杂、需要具备很多相关的专业知识，因此常常会感觉拿到数据不知从何下手。这也是我学习性能测试过程中感觉比较尴尬和棘手的事，为此我在研读了WEB 性能测试实战后特作了以下笔记，这里只是书中第4 章 WEB 应用程序性能分析的一部分，贴出来希望和大家共同讨论：一：性能分析的基础知识：精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 4 页，共 10 页1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS每秒钟处理的交易数、点击率等。2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB 服务器、数据库服务器、操作系统四个方面。3.常规、粗略的性能分析方法：当增大系统的压力或增加并发用户数时，吞吐率和TPS 的变化曲线呈大体一致，则系统基本稳定； 假设压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，很可能是网络出现带宽瓶颈，同理假设点击率/TPS 曲线出现变化缓慢或者平坦，说明服务器开始出现颈。4.作者提出了如下的性能分析基本原则，此原则本人十分赞同：由外而内、由表及里、层层深入应用此原则，分析步骤具体可以分为以下三步：第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；第二步：比较Tn网络响应时间和Ts服务器响应时间可以确定瓶颈发生在网络还是服务器；第三步：进一步分析，确定更细组件的响应时间，直到找出发生性能瓶颈的根本原因。二：以 WEB 应用程序为例来看下具体的分析方法：精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 5 页，共 10 页1.用户事务分析：a.事务综述图 (Transaction Summary ): 以柱状图的形式表现了用户事务执行的成功与失败。通过分析成功与失败的数据可以直接判断出系统是否运行正常。假设失败的事务非常多，则说明系统发生了瓶颈或者程序在执行过程中发生了问题。b.事务平均响应时间分析图Average Transaction Response Time: 该图显示在测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务的最大值、 最小值和平均值。通过它可以分析系统的性能走向。假设所有事务响应时间基本成一条曲线， 则说明系统性能基本稳定；否则如果平均事务响应时间逐渐变慢，说明性能有下降趋势，造成性能下降的原因有可能是由于内存泄漏导致。c.每秒通过事务数分析图Transaction per Second 即 TPS:显示在场景运行的每一秒中，每个事务通过、失败以及停止的数量。通过它可以确定系统在任何给定时刻的实际事务负载。 假设随着测试的进展，应用系统在单位时间内通过的事务数目在减少，则说明服务器出现瓶颈。d.每秒通过事务总数分析图Total Transactions per Second:显示场景运行的每一秒中，通过、失败以及停止的事务总数。假设在同等压力下，曲线接近直线，则性能基本趋于精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 6 页，共 10 页稳定； 假设在单位时间内通过的事务总量越来越少，即整体性能下降。原因可能是内存泄漏或者程序中的缺陷。e.事务性能摘要图Transaction Performance Summary :显示方案中所有事务的最小、最大平均执行时间，可以直接判断响应时间是否符合客户要求重点关注事务平均、最大执行时间。f.事务响应时间与负载分析图Transaction Response Time Under load:通过该图可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据。g.事务响应时间百分比图Transaction Response Time(percentile):该图是根据测试结果进行分析而得到的综合分析图。分析该图应从整体出发，假设可能事务的最大响应时间很长，但如果大多数事务具有可接受的响应时间，则系统的性能是符合。h.事务响应时间分布情况图Transaction Response Time (Distribution) :该图显示了测试过程中不同响应时间的事务数量。假设系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定系统性能是否在接受范围内。分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还需要更深入精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 7 页，共 10 页的分析。没有贴图，看起来有点费劲，如果你对这些图都比较了解，应该是比较简单的. 分析原则：? 具体问题具体分析这是由于不同的应用系统，不同的测试目的，不同的性能关注点? 查找瓶颈时按以下顺序，由易到难。服务器硬件瓶颈-网络瓶颈对局域网，可以不考虑-服务器操作系统瓶颈参数配置 -中间件瓶颈参数配置，数据库，web 服务器等 -应用瓶颈 SQL 语句、数据库设计、业务逻辑、算法等注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力并发用户数、数据量下，系统的硬件瓶颈在哪儿就够了。? 分段排除法很有效分析的信息来源：?1 根据场景运行过程中的错误提示信息?2 根据测试结果收集到的监控指标数据一错误提示分析分析实例：1 ?Error: Failed to connect to server “ payment.baihe : 1 0060 Connection ?Error: timed out Error: Server “ user.baihe 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 。否则，再根据各服务器的资源情况和业务操作响应时间精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 8 页，共 10 页进一步分析原因所在。2业务操作响应时间：? 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“ 事务性能摘要” 图，可以确定在方案执行期间响应时间过长的事务。? 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？? 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“ 网络监视器 ” 图确定导致性能瓶颈的网络问题2-5-10 原则：简单说，就是当用户能够在2 秒以内得到响应时，会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10 秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10 秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web 站点，或者发起第二次请求3服务器资源监控指标：内存：1 UNIX 资源监控中指标内存页交换速率Paging rate ，如果该值偶尔走高，说明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。2 Windows 资源监控中， 如果 ProcessPrivate Bytes 计数器和ProcessWorking Set 计数器的值在长时间内持续升高，同时MemoryAvailable 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资源监控中，如果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 Time 和 Avg.Disk Queue Length 的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 9 页，共 10 页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的大小。2 如果数据的缓存命中率小于0.90， 那么需要加大DB_BLOCK_BUFFERS参数的值 单位：块 。3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER 参数的值。4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以防止磁盘排序。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 10 页，共 10 页
