性能测试中如何定位性能瓶颈

性能测试这种测试方式在发生过程当中，其中一个过渡性的工做，就是对执行过程当中的问题，进行定位，对功能的定位，对负载的定位，最重要的，固然就是问题中说的“瓶颈”，接触性能测试不深，更非专家，本身的理解，瓶颈产生在如下几方面：

• 一、网络瓶颈，如带宽，流量等造成的网络环境
• 二、应用服务瓶颈，如中间件的基本配置，CACHE等
• 三、系统瓶颈，这个比较经常使用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置
• 四、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置
• 五、应用程序自己瓶颈，

针对网络瓶颈，如今冒似不多，不过也不是没有，首先想一下若是有网络的阻塞，断网，带宽被其余资源占用，限速等状况，应用程序或系统会是什么状况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，须要服务器返回的信息获取不到还有一种更明显的状况，应该就是事务提交慢，若是封装事务的代码再不完善，通常形成的错误，无非就是数据提交不完整，或者由于网终缘由+代码缺陷形成重复性提交。如此综合下来，确定是考虑网络有瓶颈，而后考虑网络有问题时，怎样去优化，是须要优化交互的一些代码，仍是接口之类的。

应用服务的瓶颈的定位，比较复杂，学习中，不过网上有不少资料能够参考的。通常像tomcat，weblogic之类的，有默认的设置，也有通过架构和维护人员进行试验调试的一些值，这些值通常能够知足程序发布的须要，没必要进行太多的设置，可能咱们认识的最基本的就是JAVA_OPTS的设置，maxThreads，time_out之类的参数咱们作借助LR，Jemeter或webload之类的工具，执行性能测试，尤为是对应用服务形成了压力，若是应用服务有瓶颈，通常咱们设置的log4j.properties，日志都会记录下来。而后根据日志，去进一步肯定应用服务的问题

系统瓶颈，这个定位虽然说比较复杂，可是有不少前辈的经验值参考，不做说明，相信用LR的同行，也能够从性能记数器中得出一些指标值，加上nagios，cacti，能够很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，通常系统瓶颈的形成，是由于应用程序自己形成的。关于这点儿的分析和定位，就须要纳入应用程序自己瓶颈分析和定位了。

如今基本全部的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工做，数据库管理员平常作的工做，可能就是有瓶颈定位的工做，好比：查询一下V$sys_event，V$sysstat，v$syssql之类的表，比对一下平常正常状况下的监控数据，看一下有没有异常等。其余方面，我也不是太了解。

应用程序瓶颈，这个是测试过程当中最须要去关注的，须要测试人员和开发人员配合执行，而后定位，我这儿作的大都是执行性的，好比会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的状况肯定哪儿有问题。大体是这样，没有实际操做过

逐步细化分析，先能够监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，而后根据所测系统具体状况，进行初步问题定位，而后肯定更详细的监控指标来分析。

怀疑内存不足时：

方法1：

【监控指标】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec

【参考值】：

若是 Page Reads/Sec 比率持续保持为 5，表示可能内存不足。

Page/sec 推荐00-20（若是服务器没有足够的内存处理其工做负荷，此数值将一直很高。若是大于80，表示有问题）。

方法2：根据Physical Disk 值分析性能瓶颈

【监控指标】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length

【参考值】：%Disk Time建议阈值90%

当内存不足时，有点进程会转移到硬盘上去运行，形成性能急剧降低，并且一个缺乏内存的系统经常表现出很高的CPU利用率，由于它须要不断的扫描内存，将内存中的页面移到硬盘上。

怀疑内存泄漏时

【监控指标】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time

【说明】：

Windows资源监控中，若是Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续下降，则极可能存在内存泄漏。内存泄漏应该经过一个长时间的，用来研究分析当全部内存都耗尽时，应用程序反应状况的测试来检验。

CPU分析

【监控指标】：

System %Processor Time CPU，Processor %Processor Time CPU

Processor%user time 和Processor%Privileged Time

system\Processor Queue Length

Context Switches/sec 和%Privileged Time

【参考值】：

System\%Total processor time不持续超过90%，若是服务器专用于SQL Server，可接受的最大上限是80-85% ，合理使用的范围在60%至70%。

Processor %Processor Time小于75%

system\Processor Queue Length值，小于CPU数量的总数+1

CPU瓶颈问题

一、System\%Total processor time若是该值持续超过90%，且伴随处理器阻塞，则说明整个系统面临着处理器方面的瓶颈.

注：在某些多CPU系统中，该数据虽然自己并不大，但CPU之间的负载情况极不均衡，此时也应该视做系统产生了处理器方面的瓶颈.

二、排除内存因素，若是Processor %Processor Time计数器的值比较大，而同时网卡和硬盘的值比较低，那么能够肯定CPU 瓶颈。（内存不足时，有点进程会转移到硬盘上去运行，形成性能急剧降低，并且一个缺乏内存的系统经常表现出很高的CPU利用率，由于它须要不断的扫描内存，将内存中的页面移到硬盘上。）

形成高CPU使用率的缘由：

频繁执行程序，复杂运算操做，消耗CPU严重

数据库查询语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出现瓶颈

内存不足，IO磁盘问题使得CPU的开销增长

磁盘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方式了.

Average Transaciton Response Time（事务平均响应时间）随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，总体性能将会有降低的趋势

Transactions per Second（每秒经过事务数/TPS）当压力加大时，点击率/TPS曲线若是变化缓慢或者有平坦的趋势，颇有多是服务器开始出现瓶颈

Hits per Second（每秒点击次数）经过对查看“每秒点击次数”，能够判断系统是否稳定。系统点击率降低一般代表服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

Throughput（吞吐率）能够依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

Connections（链接数）当链接数到达稳定状态而事务响应时间迅速增大时，添加链接可使性能获得极大提升（事务响应时间将下降）

Time to First Buffer Breakdown（Over Time）（第一次缓冲时间细分（随时间变化））可使用该图肯定场景或会话步骤运行期间服务器或网络出现问题的时间。

碰到过的性能问题：

• 1. 在高并发的状况下，产生的处理失败（好比：数据库链接池太低，服务器链接数超过上限，数据库锁控制考虑不足等）
• 2. 内存泄露（好比：在长时间运行下，内存没有正常释放，发生宕机等）
• 3. CPU使用偏离（好比：高并发致使CPU使用率太高）
• 4. 日志打印过多，服务器无硬盘空间

如何定位这些性能问题：

1. 查看系统日志，日志是定位问题的不二法宝，若是日志记录的全面，很容易经过日志发现问题。

好比，系统宕机时，系统日志打印了某方法执行时抛出out of memory的错误，咱们就能够顺藤摸瓜，很快定位到致使内存溢出的问题在哪里。

2. 利用性能监控工具，好比：JAVA开发B/S结构的项目，能够经过JDK自带的Jconsole，或者JProfiler，来监控服务器性能，Jconsole能够远程监控服务器的CPU，内存，线程等状态，并绘制变化曲线图。

利用Spotlight能够监控数据库使用状况。

咱们须要关注的性能点有：CPU负载，内存使用率，网络I/O等

3. 工具和日志只是手段，除此以外，还须要设计合理的性能测试场景

具体场景有：性能测试，负载测试，压力测试，稳定性测试，浪涌测试等

好的测试场景，能更加快速的发现瓶颈，定位瓶颈

4. 了解系统参数配置，能够进行后期的性能调优

除此之外，还想说个题外话，就是关于性能测试工具的使用问题

在刚开始用Loadrunner和JMeter的时候，作高并发测试时，都出现过没有把服务器压垮，这两个程序本身先倒下的状况。

若是遇到这个问题，能够经过远程调用多个客户端的服务，分散性能测试工具客户端的压力来解决。