《2022年性能测试结果分析.docx》由会员分享，可在线阅读，更多相关《2022年性能测试结果分析.docx（17页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精选学习资料 - - - - - - - - - 性能测试工程师基本上都能够把握利用测试工具来作负载、压力测试, 但多数人对怎样去分析工具收集到的测试结果感到无从下手,下面我就把个人工作中的体会和收集到的有关资料整理出来,期望能对大家分析测试结果有所帮忙；分析原就：1. 详细问题详细分析这是由于不同的应用系统,不同的测试目的,不同的性能关注点2. 查找瓶颈时按以下次序,由易到难；服务器硬件瓶颈-网络瓶颈对局域网,可以不考虑-服务器操作系统瓶颈参数配置 -中间件瓶颈参数配置,数据库,库设计、业务规律、算法等web 服务器等 -应用瓶颈 SQL 语句、数据注：以上过程并不是每个分析中都需要的,要依
2、据测试目的和要求来确定分析的深度；对一些要求低的,我们分析到应用系统在将来大的负载压力并发用户数、数据量下,系 统的硬件瓶颈在哪儿就够了；3 分段排除法 很有效 分析的信息来源：1 依据场景运行过程中的错误提示信息 2 依据测试结果收集到的监控指标数据一错误提示分析 分析实例：1 Error: Failed to connect to server “ .30:8080 : 10060 Connection Error: timed out Error: Server “ .30has shut down 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、大导致服务器的瓶颈名师归纳总结 - - - - - - -第 1 页,共 10 页精选学习资料 - - - - - - - - - B、页面中图片太多C、在程序处理表的时候检查字段太大多二监控指标数据分析1最大并发用户数：应用系统在当前环境硬件环境、网络环境、软件环境参数配置用户数；在方案运行中,假如显现了大于 3 个用下能承担的最大并发户的业务操作失败,或显现了服务器 shutdown 的情形,就说明在当前环境下,系统承担不了当前并发用户的负载压力,数；那么最大并发用户数就是前一个没有显现这种现象的并发用户假如测得的最大并发用户数到达了性能要求,且各服务器资源情形良好,业务操作响应时间也到达
5、了用户要求,那么 进一步分析缘由所在；2业务操作响应时间：OK ；否就,再依据各服务器的资源情形和业务操作响应时间分析方案运行情形应从平均事务响应时间图和事务性能摘要图开头；使用“ 事务性能 摘要” 图,可以确定在方案执行期间响应时间过长的事务；细分事务并分析每个页面组件的性能；的？问题是否与网络或服务器有关？查看过长的事务响应时间是由哪些页面组件引起假如服务器耗时过长, 请使用相应的服务器图确定有问题的服务器度量并查明服务器性能 下降的缘由；假如网络耗时过长,请使用“ 网络监视器” 图确定导致性能瓶颈的网络问题3服务器资源监控指标：内存：1 UNIX 资源监控中指标内存页交换速率Paging
6、 rate,假如该值有时走高,说明当时有线程竞争内存；假如连续很高,就内存可能是瓶颈；也可能是内存拜访命中率低；2 Windows 资源监控中, 假如 ProcessPrivate Bytes 计数器和 ProcessWorking Set 计数器的值在长时间内连续上升,同时 存泄漏；MemoryAvailable bytes 计数器的值连续降低,就很可能存在内内存资源成为系统性能的瓶颈的征兆 : 很高的换页率 high pageout rate; 进程进入不活动状态 ; 交换区全部磁盘的活动次数可高 ; 可高的全局系统 CPU 利用率 ; 内存不够出错 out of memory error
7、s 处理器：名师归纳总结 - - - - - - -第 2 页,共 10 页精选学习资料 - - - - - - - - - 1 UNIX 资源监控 Windows 操作系统同理中指标CPU 占用率 CPU utilization ,假如该值连续超过 95%,说明瓶颈是 CPU；可以考虑增加一个处理器或换一个更快的处理器；如果服务器专用于 SQL Server,可接受的最大上限是 80-85% 合理使用的范畴在 60%至 70%；2 Windows 资源监控中,假如 SystemProcessor Queue Length 大于 2,而处理器利用率Processor Time始终很低,就存在着
8、处理器堵塞；CPU 资源成为系统性能的瓶颈的征兆 : 很慢的响应时间 slow response time CPU 闲暇时间为零 zero percent idle CPU 过高的用户占用 CPU 时间 high percent user CPU 过高的系统占用 CPU 时间 high percent system CPU 长时间的有很长的运行进程队列磁盘 I/O：large run queue size sustained over time 1 UNIX 资源监控 Windows 操作系统同理中指标磁盘交换率Disk rate,假如该参数值始终很高,说明 I/O 有问题；可考虑更换更快的硬
9、盘系统；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 ratenot sufficie
10、nt in itself 过低的缓存命中率 low buffer cache hit rationot sufficient in itself 太长的运行进程队列,但 CPU 却闲暇 large run queue with idle CPU 4数据库服务器：SQL Server 数据库：1 SQLServer 资源监控中指标缓存点击率80%,应考虑增加内存；Cache Hit Ratio ,该值越高越好；假如连续低于2 假如 Full Scans/sec全表扫描 /秒计数器显示的值比 1 或 2 高,就应分析你的查询以确定是否的确需要全表扫描,以及SQL 查询是否可以被优化；3 Numbe
11、r of Deadlocks/sec死锁的数量 /秒：死锁对应用程序的可伸缩性特别有害,并且会导致恶劣的用户体验；该计数器的值必需为 0；4 Lock Requests/sec锁恳求 /秒,通过优化查询来削减读取次数,可以削减该计数器的值；Oracle 数据库：1 假如自由内存接近于 0 而且库快存或数据字典快存的命中率小于 0.90,那么需要增加SHARED_POOL_SIZE 的大小；快存共享 SQL 区和数据字典快存的命中率：selectsumpins-reloads/sumpins from v$librarycache; 名师归纳总结 - - - - - - -第 3 页,共 10
12、页精选学习资料 - - - - - - - - - selectsumgets-getmisses/sumgets 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-p
13、hysical 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 round100*b.value/decodea.value+b.value, 0, 1, a.value+b.value, 2from v$sys
14、stat a, v$sysstat b where a.name=sorts disk and b.name=sorts memory注：上述 SQL Server 和 Oracle 数据库分析,只是一些简洁、基本的分析,特殊是 Oracle 数据库的分析和优化,是一门特地的技术,进一步的分析可查相关资料；性能测试的结果分析是性能测试的重中之重；在实际工作中,由于测试的结果分析比较复杂、需要具备很多相关的专业学问,因此经常会感觉拿到数据不知从何下手；这也是我学习性能测试过程中感觉比较尴尬和麻烦的事,为此我在研读了下笔WEB 性能测试实战后特作了以记,这里只是书中第 4 章 WEB 应用程序性能
15、分析的一部分,贴出来期望和大家共同争论：一：性能分析的基础学问：名师归纳总结 - - - - - - -第 4 页,共 10 页精选学习资料 - - - - - - - - - 1.几个重要的性能指标：相应时间、吞吐量、吞吐率、击率等；TPS每秒钟处理的交易数 、点2.系统的瓶颈分为两类：网络的和服务器的；服务器瓶颈主要涉及：应用程序、WEB 服务器、数据库服务器、操作系统四个方面；3.常规、粗略的性能分析方法：当增大系统的压力或增加并发用户数时,吞吐率和 系统TPS 的变化曲线呈大体一样,就基本稳固； 假设压力增大时,吞吐率的曲线增加到肯定程度后显现变化缓慢,甚至平整,很 可能是网络显现带宽
16、瓶颈,同理假设点击率 现颈；/TPS 曲线显现变化缓慢或者平整,说明服务器开头出4.作者提出了如下的性能分析基本原就,此原就本人特别赞同：由外而内、由表及里、层层深化应用此原就,分析步骤详细可以分为以下三步：第一步：将得到的响应时间和用户对性能的期望值比较确定是否存在瓶颈；其次步：比较Tn网络响应时间和Ts服务器响应时间可以确定瓶颈发生在网络仍是服务器；第三步：进一步分析,确定更细组件的响应时间,直到找动身生性能瓶颈的根本缘由；二：以 WEB 应用程序为例来看下详细的分析方法：名师归纳总结 - - - - - - -第 5 页,共 10 页精选学习资料 - - - - - - - - - 1.
17、用户事务分析：a.事务综述图 Transaction Summary : 以柱状图的形式表现了用户事务执行的胜利与失败；通过分析胜利与失败的数据可以直接判定出系统是否运行正常；假设失败的事务特别多,就说明系统发生了瓶颈或者程序在执行过程中发生了问题；b.事务平均响应时间分析图Average Transaction Response Time: 该图显示在测试场景运行期间的每一秒内事务执行所用的平均时间,仍显示了测试场景运行时间内各个 事务的最大值、 最小值和平均值；通过它可以分析系统的性能走向；假设全部事务响应时间基本成一条曲线, 就说明系统性能基本稳固；否就假如平均事务响应时间逐步变慢,说明
18、性能有下降趋势,造成性能下降的缘由有可能是由于内存泄漏导致；c.每秒通过事务数分析图Transaction per Second 即 TPS:显示在场景运行的每一秒中,每个事 务通过、失败以及停止的数量；通过它可以确定系统在任何给定时刻的实际事务负载； 假设随着测试的进展,应用系统在单位时间内通过的事务数目在削减,就说明服务器显现瓶颈；d.每秒通过事务总数分析图Total Transactions per Second:显示场景运行的每一秒中,通过、失败以及停止的事务总数；假设在同等压力下,曲线接近直线,就性能基 本趋于名师归纳总结 - - - - - - -第 6 页,共 10 页精选学习资
19、料 - - - - - - - - - 稳固； 假设在单位时间内通过的事务总量越来越少,即整体性能下降；缘由可能是内存泄漏或者程序中的缺陷；e.事务性能摘要图Transaction Performance Summary :显示方案中全部事务的最小、最大平均执行时间,可以直接判定响应时间是否符合客户要求重点关注事务平均、最大执行时间；f.事务响应时间与负载分析图Transaction Response Time Under load:通过该图可以看出在任一时间点事务响应时间与用户数目的关系,从而把握系统在用户并发方面的性能数据；g.事务响应时间百分比图Transaction Response
20、Timepercentile :该图是依据测试结果进行分析而得到的综合分析图；分析该图应从整体动身,假设可能事务的最大响应时间很长,但假如大多数事务具有可接受的响应时间,就系统的性能是符合；h.事务响应时间分布情形图Transaction Response Time Distribution :该图显示了测试过程中不同响应时间的事务数量；假设系统预先定义了相关事务可以接受的最小和最大事务响应时间,就可以使用此图确定系统性能是否在接受范畴内；分析到这一步,只能大致判定出瓶颈可能会出在那,要详细定位瓶颈仍需要更深化名师归纳总结 - - - - - - -第 7 页,共 10 页精选学习资料 - -
21、 - - - - - - - 的分析；没有贴图,看起来有点费劲,假如你对这些图都比较明白,应当是比较简洁的 . 分析原就：. 详细问题详细分析这是由于不同的应用系统,不同的测试目的,不同的性能关注点. 查找瓶颈时按以下次序,由易到难；服务器硬件瓶颈-网络瓶颈对局域网,可以不考虑-服务器操作系统瓶颈参数配置 -中间件瓶颈参数配置,数据库,设计、业务规律、算法等web 服务器等 -应用瓶颈 SQL 语句、数据库注：以上过程并不是每个分析中都需要的,要依据测试目的和要求来确定分析的深度；对一些要求低的,我们分析到应用系统在将来大的负载压力并发用户数、数据量下,系统的 硬件瓶颈在哪儿就够了；. 分段排
22、除法 很有效 分析的信息来源：.1 依据场景运行过程中的错误提示信息 .2 依据测试结果收集到的监控指标数据 一错误提示分析 分析实例：1 .Error: Failed to connect to server “payment.baihe : 10060 Connection .Error: timed out Error: Server user.baihe has shut down the connection prematurely 分析：.A、应用服务死掉；小用户时：程序上的问题；程序上处理数据库的问题.B、应用服务没有死应用服务参数设置问题例：在很多客户端连接Weblogic 应
23、用服务器被拒绝,而在服务器端没有错误显示,就有可能是 Weblogic 中的 server 元素的 AcceptBacklog 属性值设得过低；假如连接时收到connection refused 消息,说明应提高该值,每次增加 25.C、数据库的连接1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数跟硬件的内存有关 2 Error: Page download timeout 120 seconds has expired 分析：可能是以下缘由造成.A、应用服务参数设置太大导致服务器的瓶颈.B、页面中图片太多.C、在程序处理表的时候检查字段太大多二监控指标数据分析1最大并发用户数：应
24、用系统在当前环境硬件环境、网络环境、软件环境参数配置用户数；下能承担的最大并发在方案运行中,假如显现了大于 3 个用户的业务操作失败,或显现了服务器 shutdown 的情形, 就说明在当前环境下,系统承担不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有显现这种现象的并发用户数；假如测得的最大并发用户数到达了性能要求,且各服务器资源情形良好,业务操作响应时间也到达了用户要求,那么OK ；否就,再依据各服务器的资源情形和业务操作响应时间名师归纳总结 - - - - - - -第 8 页,共 10 页精选学习资料 - - - - - - - - - 进一步分析缘由所在；2业务操作响应时
25、间：. 分析方案运行情形应从平均事务响应时间图和事务性能摘要图开头；使用“ 事务性能摘 要” 图,可以确定在方案执行期间响应时间过长的事务；. 细分事务并分析每个页面组件的性能；查看过长的事务响应时间是由哪些页面组件引起 的？问题是否与网络或服务器有关？请使用相应的服务器图确定有问题的服务器度量并查明服务器性能 . 假如服务器耗时过长,下降的缘由；假如网络耗时过长,请使用 2-5-10 原就：简洁说,就是当用户能够在“网络监视器 ” 图确定导致性能瓶颈的网络问题 2 秒以内得到响应时,会感觉系统的响应很快；当用户在 2-5 秒之间得到响应时,会感觉系统的响应速度仍可以；当用户在 5-10 秒以
26、内得到 响应时,会感觉系统的响应速度很慢,但是仍可以接受；而当用户在超过 10 秒后仍旧无法 得到响应时,会感觉系统糟透了,或者认为系统已经失去响应,而挑选离开这个 Web 站点,或者发起其次次恳求3服务器资源监控指标：内存：1 UNIX 资源监控中指标内存页交换速率Paging rate,假如该值有时走高,说明当时有线程竞争内存；假如连续很高,就内存可能是瓶颈；也可能是内存拜访命中率低；2 Windows 资源监控中, 假如 ProcessPrivate Bytes 计数器和 ProcessWorking Set 计数器的值在长时间内连续上升,同时 存泄漏；MemoryAvailable b
27、ytes 计数器的值连续降低,就很可能存在内内存资源成为系统性能的瓶颈的征兆 : 很高的换页率 high pageout rate; 进程进入不活动状态 ; 交换区全部磁盘的活动次数可高 ; 可高的全局系统 CPU 利用率 ; 内存不够出错 out of memory errors 处理器：1 UNIX 资源监控 Windows 操作系统同理中指标CPU 占用率 CPU utilization ,假如该值连续超过 95%,说明瓶颈是 CPU；可以考虑增加一个处理器或换一个更快的处理器；如果服务器专用于 SQL Server,可接受的最大上限是 80-85% 合理使用的范畴在 60%至 70%；
28、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 长时间的有很长的运行进程队列 磁盘 I/O：large run queue size sustained o
29、ver time 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 太长的磁盘等待队
30、列 large disk queue length 等待磁盘 I/O 的时间所占的百分率太高large percentage of time waiting for disk I/O 太高的物理 I/O 速率 :large physical I/O ratenot sufficient in itself 过低的缓存命中率 low buffer cache hit rationot sufficient in itself 太长的运行进程队列,但 CPU 却闲暇 large run queue with idle CPU 4数据库服务器：SQL Server 数据库：1 SQLServer 资
31、源监控中指标缓存点击率80%,应考虑增加内存；Cache Hit Ratio ,该值越高越好；假如连续低于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 页- - - - - - -