http://www.51testing.com/html/90/n-4471990.html
性能指标的监控与分析作为[性能测试](javascript:;)工作流程中重要的一环，直接关系到性能测试是否充分有效、性能测试结果是否能为系统投产提供有效参考，重要性不言而喻。
本文以性能瓶颈定位方法为主线，介绍如何运用各种性能指标进行性能瓶颈定位。报告所述指标体系包含配置参数指标体系和应用性能指标体系两部分。其中，配置参数指标体系总结了测试环境中对性能影响较大的部分参数及其参考值。在正式开始性能测试之前，可通过本套配置参数指标体系对待测系统的各项参数配置进行检验，在测试前尽早规避一些由于配置参数导致的性能瓶颈。应用性能指标体系总结了对系统性能瓶颈有影响的主要性能指标，包括应用系统、服务器、[数据库](javascript:;)、中间件等各项指标值的参考值。进而分析各指标在不同组合取值的情形下，系统可能会出现的性能瓶颈，并给出相应的瓶颈定位和性能调优方式。指标主要采用矩阵表格的形式展示，该表以各性能指标为横、纵坐标，在给出性能指标标准值（如表中的“各项性能指标标准值（保留）”行）的基础上，在指标两两组合相交的位置，给出此情况下可能会出现的性能瓶颈，以及相应的性能调优方式。
一、性能指标体系
1.1配置参数指标体系
构建配置参数指标体系的目的为在性能测试开始前，根据测试环境资源配置和待测交易的非功能需求，预先调整系统中可能影响性能的参数，提前规避由于各种配置参数带来的性能影响。
根据历史测试经验，应用系统的各项配置参数是影响系统性能的一个重要因素。经过对应用服务器、数据库服务器的大量数据收集以及研究梳理，本文总结研究出了配置参数指标体系，在该体系中详细介绍应用服务器、数据库服务器中可能对系统的性能产生影响的各种主要配置指标，并对每个指标的参考值进行了标注，为实际测试工作提供参考依据。需注意，此范围仅作参考，其具体设置值需根据各个应用系统的实际情况进行相应的调整，从而使得各参数值能给系统带来更好的性能表现。
表 1配置参数指标体系示例
本体系需要从以下几个层面去使用，第一是开始进行性能测试前，需要对照本体系将相关参数配置情况如实的[记录](javascript:;)下来，第二就是根据测试结果并对照参考值调整相应的指标。
1.2应用性能指标体系
应用性能指标体系，主要从应用系统、服务器、数据库和中间件等方面归纳收集整理主要性能指标，该体系主要收录了一些经验数据，将一些常见的性能问题及发现方式通过该体系展现出来，其目的一是为读者学习提供参考，二是为性能测试人员性能测试分析提供知识的积累，并希望能够在以后的工作中能通过这个体系模板，不断的归纳总结出一些共性问题，使得性能测试的知识得到一个积累和沉淀。
表2展示的就是该体系中的部分内容，本体系采用了一种类似矩阵的方式来展示，这样可以通过不同指标的组合，列举出一些常见的性能问题，并能够给出简单的优化建议。本体系横列为服务器、数据库和中间件的主要性能指标，纵列为应用系统最为关心的响应时间、TPS、成功率。
表 2应用系统性能指标体系示例
横列的第二行给出了这些指标的参考值范围及参考值的评价，这样可以为使用该体系的人员一个比较直观的概念，并且也能通过这些参考值范围给被测系统的性能优劣给出一个初步的判定。在横列和纵列之间主要就是针对不同指标组合可能产生什么样的性能问题以及其解决办法的描述，可以说该体系是历史经验总结沉淀下来的成果。
在实际的性能测试工作中，测试人员可以在发现系统性能问题后直接对照本体系，查看是否有类似的问题描述，如果有可以通过描述的内容快速定位问题所在，并给出一定的调优建议；如果没有类似的问题出现，需要测试人员将问题记录下来，按照常规方式定位问题所在，并总结这样的现象是否为常规的现象，如果是，需将它总结归纳到该体系中。
二、基于性能指标体系的性能瓶颈定位方法
本章介绍性能瓶颈定位方法，第一节通过流程图对整个性能瓶颈的定位方法进行全方位的说明，并以此定义出一套比较规范的查找、定位系统瓶颈的流程方法；第二节阐述以往项目性能测试过程中遇到的性能瓶颈问题和解决问题的方法、经验，总结快速定位系统性能瓶颈的方法，以便性能测试人员在实际的性能测试工作中能够快速的定位系统性能瓶颈问题所在；第三节总结各种常规的性能瓶颈定位方式，着重总结内存分析、处理器分析、磁盘I/O分析、网络分析、应用分析等几种常用的分析方法。使用者可基于这些方法和指标，结合系统的各种表象，定位、分析系统出现的性能问题所在。
2.1 性能瓶颈定位方法概述
本节首先引入两个基本概念：性能瓶颈和性能瓶颈定位。性能瓶颈为制约系统性能的最主要因素；性能瓶颈定位指为了找出制约性能的最主要的因素而展开的分析、设计、测试、比较、调优等工作。
根据影响范围的不同和触发时间的不同，我们可以将性能瓶颈分为三类：系统类、事件类和路径类。系统类的瓶颈一般表现在由于硬件、参数配置引起的一系列性能问题；事件类瓶颈为通过某些性能指标的表象分析出的系统存在的性能问题；而路径类则是由于程序本身的问题引起的性能问题，比如程序模块调用错误引起的 “http500”的错误，它需要程序员遍历程序路径定位性能问题所在。
性能瓶颈定位方法采用循序渐进的方式，逐步深入剖析性能问题所在。具体而言，实施为三个阶段：性能前期准备分析阶段、性能执行快速定位阶段、性能常规定位阶段。下面结合图1对流程各个阶段的任务和执行方式进行简要的说明。
（一）性能前期准备分析阶段
如图1所示，前两个模块描述的即为性能前期准备分析阶段，该阶段的重点在于“配置参数指标体系”（参见1.1节）。总结该体系的目的在于整理一套在不同的硬件环境配置情况下，对系统性能有影响的参数设置情况，使测试人员在性能测试正式执行之前,通过比对参数参考值和实际值，提早发现由于系统参数引起的性能问题，及早规避由于系统参数带来的性能影响，为后面的性能测试工作的开展奠定基础。
图1：性能瓶颈定位方法流程图
（二）性能执行快速定位阶段
性能执行快速定位阶段，如图1所示，包括从流程图中第三到第五个步骤。该阶段的工作建立在基于性能测试工具（在这里主要使用[LoadRunner](javascript:;)工具进行说明，以下同）进行性能测试的基础上。在使用性能工具进行性能测试过程中，可以获取一些性能指标，例如响应时间、TPS、吞吐量以及一些简单的错误信息等，通过结合一些监控工具和监控方式，例如监控系统各项指标的nmon，监控数据库性能；抓取响应时间较长的[SQL](javascript:;)，获取系统和数据库相关指标，快速定位一些常见的性能问题（具体参见1.2节）。
在此阶段里将使用到另一个重要成果“应用性能指标体系”，体系中将会描述如何组合一些关键的性能指标从而定位性能瓶颈所在。
（三）性能常规定位阶段
这一阶段的工作主要为图1所示的性能常规定位阶段。如经过第一阶段与第二阶段仍然无法发现性能问题所在，则执行此步骤。此阶段为定位性能瓶颈的高级阶段。
首先，此阶段总结性能指标，同时总结一些常用的分析方法，对性能问题进一步的剖析，使得对性能问题的定位更准确深入。例如，可以使用内存分析方法查找一些内存泄露或者硬件不足带来的性能问题，通过CPU分析方法定位一些CPU使用率持续增高带来的性能问题等。本文2.3.3章节会对该类方法进行详细阐述。
通过上述方法，本文探索一套实用流程，不仅能为性能测试初学者提供一套系统瓶颈定位的方法，也为性能测试高级人员提供了一个系统瓶颈定位的参考方向。
2.2 快速瓶颈定位
快速瓶颈定位方法，实质也是通过常规的定位方法总结出来的，由于这些性能问题较常见，且具有一定的规律性，因此可以通过一些指标进行简单的判定，就能迅速定位性能问题所在。
快速瓶颈定位可按照如下的过程来执行：
?通过性能测试工具（性能测试工具）、各种监控工具获取系统的主要性能指标。
?收集获取的各项性能指标，参照系统性能指标体系，查看是否有符合的现象产生，定位系统性能瓶颈。
?系统性能指标体系没有符合的内容可供参考，查看归纳总结的快速瓶颈定位方法。
其整个过程方法参见图2所示。
图 2：快速瓶颈定位方法
快速瓶颈定位主要还是依赖于“性能指标体系”，它将平时遇见的各种系统性能问题，通过系统各项性能指标表示出来，为性能测试人员提供一种快捷查找问题所在的方式。此外，本文还总结了一些常见的性能瓶颈问题和此类问题的解决方式的例子，为性能测试人员在性能测试过程中遇到类似的问题提供一定的帮助，示例如下：
问题1、在高并发情况下，产生的业务处理失败（比如：数据库连接池过低，服务器连接数超过上限，数据库锁控制考虑不足等）。
定位性能问题方式：查看系统日志。系统日志是定位问题的不二法宝，如果日志记录全面，很容易通过日志发现问题。比如，系统宕机时，系统日志打印了某方法执行时抛出的out of memory错误，性能测试人员就可以顺藤摸瓜，很快定位到内存溢出的问题。
问题2、内存泄露（比如：在长时间运行下，内存没有正常释放，引起宕机等）。
定位性能问题方式：利用性能监控工具。比如：[JAVA](javascript:;)开发B/S结构的项目，可以通过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole可以远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。利用Spotlight可以监控数据库使用情况。性能测试人员需要关注的性能点有：CPU负载，内存使用率，网络I/O等。
问题3、CPU使用偏离（比如：高并发导致CPU使用率过高）。
定位性能问题方式：工具和日志只是手段，除此之外，还需要设计合理的性能测试场景。具体场景有：性能测试，负载测试，[压力测试](javascript:;)，稳定性测试，浪涌测试等,好的测试场景，能更加快速的发现瓶颈，定位瓶颈。
问题4、日志打印过多，服务器无硬盘空间。
定位性能问题方式：性能测试人员通过了解系统参数配置，进行后期的性能调优。
问题5、使用性能测试工具做系统高并发，系统服务器运行正常，客户端程序出现未响应。
定位性能问题方式：通过分析，系统服务器运行正常，说明问题不在服务器。客户端程序出现未响应，由于是高并发测试，说明客户端程序出现多线程调用死锁。性能测试人员可以通过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决。本文通过提出、定位、解决该问题的例子，提醒性能测试人员关注测试过程中的性能瓶颈不应该发生在测试脚本和测试工具上。
2.3 常规瓶颈定位方法
系统性能瓶颈普遍表象为响应时间长或者占用系统资源大，因此，单纯从某些性能指标往往难以判定系统到底在哪个层面出现了问题。通过对性能测试工作的不断积累、提炼，本文总结了一个非常有用的规律：在常规软件性能测试中，可遵从“二八原则”，即70-80%的性能问题与应用程序相关，70-80%的应用程序问题与SQL语句相关，70-80%的SQL语句问题与索引、存储过程、关联查询、临时表等有关。因此，在常规瓶颈定位方法中，性能测试人员可以从SQL语句的优化进行着手，然后辅助其他方法逐步定位其它的性能瓶颈。
图 3：常规瓶颈定位方法
在进行常规瓶颈定位方法时，性能测试人员可以参照如下的步骤来进行问题的定位：
（1）、通过性能测试工具（性能测试工具）和监控工具，获取到系统的相关性能测试结果和各种性能指标。
（2）、抓取长事务SQL语句（一般认为执行周期1秒以上的SQL语句都需要关注），进行SQL语句分析。
（3）、结合获取的性能结果和性能指标，分析性能问题所在。
（4）、结合应用性能指标体系，采用SQL分析法，内存分析法、CPU分析法、磁盘I/O分析法、应用程序分析法等综合深入分析性能问题。
（5）、通过分析方法给出优化建议，完成瓶颈定位。
图三说明了进行瓶颈定位的步骤和流程，下面就各种定位方法进行详细的介绍。
2.3.1 数据库、SQL语句分析法
性能测试人员在进行性能测试过程中，判定一个功能点存在性能问题，最直观的感觉就是系统响应时间长、CPU使用率高或者内存消耗大。按照80%的性能问题都是由于SQL引起这一规律，性能测试人员首先应该从数据库、SQL语句着手。在进行性能测试的过程中，性能测试人员分析执行时间较长的SQL语句，然后按照执行时间从长到短进行分析，一般先判断是否存在表扫描，在ISQL、SQLPLUS界面可以分别采用如下的语句进行判断:
Sqlplus下查看SQL执行计划的两种种方法：
1、set autotrace on;set autotrace off;
2、Sqlplus下执行EXPLAIN PLAN FOR sql语句，然后执行
SQL>select * from table(dbms_xplan.display)
ISQL下查看SQL执行的方法：
图 4：表扫描判定语句
执行上面的语句后，工具会自动把执行这条语句所用到的表、索引、执行时间打印出来，它在数据库的术语叫查询计划，如图五所示，在界面中可以通过查找“table scan”来确定哪个表存在表扫描，如图五所示，可以看到存在表扫描的标识“TB_POST_POSITION”,从而成功定位系统瓶颈。
图 5：存在表扫描的sql语句的查询计划
除了常见的表扫描会使得被测试功能点响应时间变的很慢，系统资源使用较高外，SQL语句的书写和优化对于应用系统的性能具有至关重要的作用，SQL语句主要包括增、删、改、查，where后条件的语句书写是个非常重要的优化点，在建立正确索引的基础上，SQL语句执行条件的设定对性能优劣至关重要：
（1）、where 条件左边最好不要使用函数，比如 select ... where datediff(day,date1,getdate())>0 这样即使在 date1 列上建立了索引，也可能不会被使用，而使用表扫描。这样的语句要重新规划设计，保证不使用函数也能够实现。此外尽量避免使用诸如like '%ab'的形式,不能充分利用索引。
（2）、在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接。
（3）、两个比较字段最好使用相同数据类型，而不是兼容数据类型，比如 int 与 numeric。
（4）、复合索引的非前导列做条件时，基本没有起到索引的作用。
比如：create index idx_tablename_ab on tablename(a,b)
update tablename set c = XX where b>= XXX and ...
在这个语句中，基本上索引没有发挥作用。导致表扫描引起blocking，甚至运行十几分钟后报告失败。定位到该瓶颈后，可以通过增加附件条件进行如下改进：update tablename set c = XX where a = XXX and b>= XXX 或者建立索引类似于 create index idx_tablename_ba on tablename(b,a)。
（5）、多个大表的关联查询，如果性能不好，并且其中一个大表中取的数据比较少，可以考虑将查询分两步执行。先将一个大表中的少部分数据取出 select * into #1 from largetable1 where ...然后再用 #1 去做关联，效果会显著提高。（前提：生成 #1表应该使用比较好的索引，速度比较快）。
（6）、字段提取要按照“需多少、提多少”的原则，避免直接使用“select *”。
(7)、tempdb 的使用。最好多用 select into ，这样数据库不会写日志，尤其是系统有大量数据的报表时，该方法尤其重要。（虽然写起来麻烦，但执行效率很高。）如果使用create table #tmp1 (......)语句，在系统频繁使用时，容易发生tempdb争用，引发系统性能瓶颈。
2.3.2 内存分析法
内存出现性能问题一般有两种情况，一是内存不足，二是内存泄露。下面，分别从这两种情况介绍如何通过指标查看系统是否出现内存问题。
(1)、如果怀疑内存不足时，可以从下面两种方法确认。
方法1：通过topas（[linux](javascript:;)为top）或者nmon命令，查看Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec。如果 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。Page/sec 推荐00-20（如果服务器没有足够的内存处理其工作负荷，此数值将一直很高。如果大于80，表示有问题）。
方法2：根据Physical Disk 值分析性能瓶颈,通过topas（linux为top）或者nmon命令，查看Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length性能指标。
%Disk Time建议阈值90%，当内存不足时，有点进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。
(2)、怀疑内存泄漏
通过监控工具，监控Memory Available MBytes，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time等性能指标。[Windows](javascript:;)资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。内存泄漏应该通过一个长时间的，用来研究分析当所有内存都耗尽时，应用程序反应情况的测试来检验。
2.3.3 CPU分析法
对CPU指标进行分析，从而查找CPU的瓶颈。在测试过程中，需要监控System %Processor Time CPU，Processor %Processor Time，CPU Processor%user time，Processor%Privileged Time，system\Processor Queue Length，ontext Switches/sec 和%Privileged Time等各项与CPU相关的性能指标。
性能指标的System%Total processor time不持续超过90%，如果服务器专用于数据库，可接受的最大上限是80-85%，合理使用的范围在60%至70%。Processor %Processor Time小于75%，system\Processor Queue Length值小于CPU数量的总数+1。出现下面几种情况说明CPU可能出现性能问题：
（1）、System%Total processor time如果该值持续超过90%，且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈。
注：在某些多CPU系统中，该数据虽然本身并不大，但CPU之间的负载状况极不均衡，此时也应该视作系统产生了处理器方面的瓶颈。
（2）、排除内存因素，如果Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么可以确定为CPU 瓶颈。内存不足时，进程会转移到硬盘上去运行，造成性能急剧下降，而且一个缺少内存的系统常常表现出很高的CPU利用率，因为它需要不断的扫描内存，将内存中的页面移到硬盘上。
此外造成高CPU使用率的原因一般还存在于如下的情况中，在性能测试过程中也必须密切关注：
频繁执行程序，复杂运算操作，消耗CPU严重。
数据库查询语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出现瓶颈。
内存不足，IO磁盘问题使得CPU的开销增加。
Linux操作系统CPU利用率高：通过top命令查看CPU占用率高的进程，再根据进程PID查看CPU占用率高的线程ID（top -Hp 进程PID），将线程ID转换为16进制，生成javacore文件（Kill - 3 进程PID），利用16进制的线程ID在javacore文件中查看线程的详细执行信息，从而定位CPU利用率高的应用程序代码。
[Oracle](javascript:;)数据库服务器CPU利用率高：通过top命令查看CPU占用率高的进程PID，通过进程PID定位出sql语句的sql_id(select sql_id from vprocess where spid=’XXXX’)),通过sql_id查看具体sql(select sql_text from v$sql where sql_id=’XXXX’), 再通过dbms_xplan.display_awr（）与sql_id（select plan_table_out from table（dbms_xplan.display_awr(‘XXXX’)))查看语句的执行计划，进而对sql语句进行优化。
2.3.4 磁盘I/O分析法
磁盘的性能指标在性能测试过程中是一个比较重要的指标，在性能测试过程中，性能测试人员主要应该关注PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length，Disk sec/Transfer等性能指标，其中%Disk Time建议阈值为90%，当指标出现如下所示的各种情况时，应考虑磁盘的性能瓶颈。
Windows资源监控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
Processor%Privileged Time该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大， 那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。
Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。
2.3.5 网络分析方法
网络分析是一件[技术](javascript:;)含量很高的工作，在一般的组织中都有专门的网络管理人员进行网络分析，对测试工程师来说，如果怀疑网络是系统的瓶颈，可以通过设置特定的场景模拟网络环境进行网络方面的检测。
网络分析方法用到的计数器主要有：Network Interface\Bytes Total/sec 。Network Interface\Bytes Total/sec为发送和接收字节的速率，可以通过该计数器值来判断网络链接速度是否是瓶颈，具体操作方法是用该计数器的值和目前网络的带宽进行比较。如果该比值较大说明网络可能出现瓶颈，需要观察具体的网络流量进行进一步的判断。
2.3.6 应用分析方法
应用分析方法是性能测试过程中最直观的分析方法，它一般是其他分析方法的基础，可以直观的从测试工具执行的结果中得到相应的结果，它主要关注的指标有：平均事务响应时间、每秒事务通过率、吞吐量等。
Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
Transactions per Second（每秒通过事务数/TPS）当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈
Hits per Second（每秒点击次数）通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
Throughput（吞吐率）可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。
Connections（连接数）当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。
Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。