性能测试工程师基本上都可以掌握利用测试工具来做负载、压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把我的工做中的体会和收集到的有关资料整理出来，但愿能对你们分析测试结果有所帮助。 分析原则：web
1. 具体问题具体分析（这是因为不一样的应用系统，不一样的测试目的，不一样的性能关注点）算法
2. 查找瓶颈时按如下顺序，由易到难。数据库
服务器硬件瓶颈-〉网络瓶颈（对局域网，能够不考虑）-〉服务器操做系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并非每一个分析中都须要的，要根据测试目的和要求来肯定分析的深度。对一些要求低的，咱们分析到应用系统在未来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。缓存
3 分段排除法 颇有效
分析的信息来源：
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数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。
性能测试的结果分析是性能测试的重中之重。在实际工做中，因为测试的结果分析比较复
杂、须要具有不少相关的专业知识，所以经常会感受拿到数据不知从何下手。这也是我学习性能
测试过程当中感受比较尴尬和棘手的事，为此我在研读了《WEB性能测试实战》后特做了如下笔
记，这里只是书中第4章WEB应用程序性能分析的一
部分，贴出来但愿和你们共同讨论：
一：性能分析的基础知识：
1.几个重要的性能指标：相应时间、吞吐量、吞吐率、TPS（每秒钟处理的交易数）、点
击率等。
2.系统的瓶颈分为两类：网络的和服务器的。服务器瓶颈主要涉及：应用程序、WEB服务
器、数据库服务器、操做系统四个方面。
3.常规、粗略的性能分析方法：
当增大系统的压力（或增长并发用户数）时，吞吐率和TPS的变化曲线呈大致一致，则系统
基本稳定；若压力增大时，吞吐率的曲线增长到必定程度后出现变化缓慢，甚至平坦，极可能是
网络出现带宽瓶颈，同理若点击率/TPS曲线出现变化缓慢或者平坦，说明服务器开始出现颈。
4.做者提出了以下的性能分析基本原则，此原则本人十分赞同：
——由外而内、由表及里、层层深刻
应用此原则，分析步骤具体能够分为如下三步：
第一步：将获得的响应时间和用户对性能的指望值比较肯定是否存在瓶颈；
第二步：比较Tn（网络响应时间）和Ts（服务器响应时间）能够肯定瓶颈发生在网络仍是服
务器；
第三步：进一步分析，肯定更细组件的响应时间，直到找出发生性能瓶颈的根本缘由。
二：以WEB应用程序为例来看下具体的分析方法：
1.用户事务分析：
a.事务综述图(Transaction Summary ):以柱状图的形式表现了用户事务执行的成功与
失败。经过分析成功与失败的数据能够直接判断出系统是否运行正常。若失败的事务很是多，则
说明系统发生了瓶颈或者程序在执行过程当中发生了问题。
b.事务平均响应时间分析图（Average Transaction Response Time）: 该图显示在
测试场景运行期间的每一秒内事务执行所用的平均时间，还显示了测试场景运行时间内各个事务
的最大值、最小值和平均值。经过它能够分析系统的性能走向。若全部事务响应时间基本成一条
曲线，则说明系统性能基本稳定；不然若是平均事务响应时间逐渐变慢，说明性能有降低趋势，
形成性能降低的缘由有多是因为内存泄漏致使。
c.每秒经过事务数分析图（Transaction per Second即TPS）:显示在场景运行的每一
秒中，每一个事 务经过、失败以及中止的数量。经过它能够肯定系统在任何给定时刻的实际事务
负载。若随着测试的进展，应用系统在单位时间内经过的事务数目在减小，则说明服务器出现瓶
颈。
d.每秒经过事务总数分析图（Total Transactions per Second）:显示场景运行的
每一秒中，经过、失败以及中止的事务总数。若在同等压力下，曲线接近直线，则性能基本趋于
稳定；若在单位时间内经过的事务总量愈来愈少，即总体性能降低。缘由多是内存泄漏或者程
序中的缺陷。
e.事务性能摘要图（Transaction Performance Summary）:显示方案中全部事务的
最小、最大平均执行时间，能够直接判断响应时间是否符合客户要求（重点关注事务平均、最大
执行时间）。
f.事务响应时间与负载分析图（Transaction Response Time Under load）:经过
该图能够看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性
能数据。
g.事务响应时间（百分比）图（Transaction Response Time(percentile)）:该
图是根据测试结果进行分析而获得的综合分析图。分析该图应从总体出发，若可能事务的最大响
应时间很长，但若是大多数事务具备可接受的响应时间，则系统的性能是符合。
h.事务响应时间分布状况图（Transaction Response Time (Distribution)）:该
图显示了测试过程当中不一样响应时间的事务数量。若系统预先定义了相关事务能够接受的最小和最
大事务响应时间，则可使用此图肯定系统性能是否在接受范围内。
分析到这一步，只能大概判断出瓶颈可能会出在那，要具体定位瓶颈还须要更深刻
的分析。没有贴图，看起来有点费劲，若是你对这些图都比较了解，应该是比较简单的.