性能测试瓶颈分析

性能测试的目标是什么，业务处理能力能否达到目标；响应时间是否达到目标；能处理极限的业务能力是多少；在达到需求的业务处理能力情况下，系统资源使用是否合理；系统在长时间运行下是否稳定可靠等等等等。

 

　　而性能测试在针对目标执行过程中，其中一个过渡性的工作，就是在执行过程中，对问题点的定位。我所遇到的瓶颈产生在以下几方面：

 

1、应用服务瓶颈，如中间件的基本配置，JVM，应用连接数，DB连接数，CACHE等

2、网络瓶颈，容易忽视却又容易后悔忽视。

3、系统瓶颈：应用服务器，数据库服务器以及压力机的CPU，内存，硬盘，网卡等配置

4、数据库瓶颈，以ORACLE为例，连接池，PGA，SGA，表的索引，分区等

5、应用程序本身瓶颈，

 

网络瓶颈：看起来不太重要，而且我们大多是考虑我们的服务器出口是否够大，却忽略了用户端的需求。

　       在百兆局域网内，完整带宽为100M bps，转换成Byte，为100M/8=12.5 MB/S.

根据经验，一般网络带宽瓶颈参数为0.7，即占用网络带宽70%以上，即可视为出现网络瓶颈。因此，实际有效带宽为12.5MB/S * 70% = 8.75MB/S。如一个访问首页， JavaScript文件过大，其中ext-all-debug.js文件高达1.05MB，而如果登陆的TPS为21， 则服务器出口的网络吞吐率=21*1.05=22.05MB/S(假设访问首页只加载这一个JS文件)，而如果此时网络宽带为100M bps，肯定会出现网络瓶颈。

　因此在百兆局域网内，能达到的TPS为8.75M/1.05= 8.3。

如果用户的带宽为2M bps，转换成Byte，2M bps/8=250KB/S，而且实际2M的宽带肯定达不到250KB/S，此时访问一次首页需要的时间=1.05MB/250KB=4.2S。访问一个首页就需要4.2S，而且这4.2S完全是消耗在网络上的时间。

　　　推论：网络瓶颈的表现为系统响应速度变慢，但实际上应用服务器却是空闲状态。

设想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线。服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因加代码缺陷造成重复性提交。

 

 

应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，Jboss之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，JVM大小，应用连接数，DB连接数等，这些一般都按经验来进行修改，在执行性能测试过程中，实时监控这些数值，看连接数是否达到上线，对于连接数还需要注意实例，如果有多个实例，他们的连接数是算所有实例的总值。JVM的监控在后面讲。一般的配置为最小值1024，最大值2048，或者最小最大值都为2048。还有日志的级别，日志有两种，一种是为应用程序专门开发的日志模块，用来记录日常数据操作，另一种是中间件自己的日志，而这个日志级别主要是针对中间件自己的日志，因为遇到过该类问题，一次测试过程中，发现场景执行1个小时后，响应时间突然猛增，发现磁盘IO很高，最后才发现是Jboss的日志级别为debug，后天在疯狂执行日志写入，最后1个小时后导致了磁盘空间不足。一般建议在做性能测试时，没特殊情况把中间件日志级别设置为ERROR。还有一个参数就是 time_out，这个也可以在loadrunner进行调整。

 

系统瓶颈，可以从性能记数器中得出一些指标值，加上 nagios，nmon之类的，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。关于CPU瓶颈，

关于CPU瓶颈：1、System %total processor time该值持续超过90％，很慢的响应时间，CPU空闲时间为零，过高的用户占用CPU时间(%User Time)，过高的系统占用CPU时间(%Priviliaged Time：长期大于90%或者95%)

2、CPU的平均负载数(通过Top，uptime命令都可以看到)：cpu的利用率通常会把每个核上的占用率加起来，所以有时可能超过100%。cpu的负载和利用率之间没有必然的联系，有时会出现负载过高，但利用率不高的情况。例如，有大量的并发任务，但是每个任务的cpu占有率却很低，这时就会出现cpu负载过高利用率低下的问题。同样也会出现cpu的利用率很高，但cpu负载很低的现象。CPU负载值一般小于CPU总核数*0.7。

注：在某些多CPU系统中，CPU利用率虽然不高，但CPU之间的负载状况极不均衡，此时也应当做CPU的瓶颈。

3、排除内存因素，如果Processor %Processor Time计数器的值比较大，而网络和硬盘IO比较低，那么可以确定CPU瓶颈。（内存不足时，会使用到swap区，而是用swap时会造成大量的磁盘IO，而且很高的CPU利用率，因为需要不断的扫描内存，将内存上的页面内容写入硬盘。）

造成高CPU使用率的原因：

频繁执行代码，复杂的运算操作，大量消耗CPU。

数据库服务器上的sql语句复杂，大量的 where 子句，order by， group by 排序等，CPU容易出現瓶頸

内存不足，硬盘IO消耗CPU。

关于内存瓶颈：http://miao123551.blog.163.com/blog/static/4407816520126323647900/

关于磁盘瓶颈：现在一般都使用RAID方式，磁盘IO瓶颈一般较少，没遇到过这类问题，所以也没法描述。

监控指标：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer

 

 

数据库瓶颈：

基本所有的玩意，都离不开数据库这个后台，数据库的瓶颈因为我也只了解一丁点，实在是不知道是什么概念，只大概了解了几个参数，PGA，SGA，连接数。

在性能测试执行过程中，监控缓冲区命中率，共享区命中率，SQL软解析的百分比，闩锁命中率，其他锁等待的情况，比如数据缓冲区命中率很低，看是不是SGA太小，或者执行的SQL有太多全表扫描，导致数据交换量太大，修改一下SQL尽量不要用全表扫描，或修改SGA的DB_BLOCK_BUFFERS大小。如果SQL的软解析百分比很低，说明SQL没有被重用，或者同样的SLQ没有绑定变量，客户端每发送一个请求，SQL都要解析一次，造成CPU消耗。还有就是数据库各种锁的情况，可以通过监控工具或oracle自带的表视图进行查看。       

比如发现一个事务响应时间非常长，通过LR的网页细分图分析，看响应时间主要消耗在哪里，如果消耗在服务器，排除应用服务器问题，此时可以先用工具比如spotlight查看后台数据库执行的消耗，用top sql功能查找出执行的SQL，如果SQL消耗时间差不多了整个事务的响应时间，分析出是SQL本身问题还是数据表的原因(表的数据量太大，没加索引。或者表做了分区，要去查询几个分区的数据)。

 

应用程序瓶颈，这个是测试过程中最需要去关注的，而大多也是去关注线程数，堆内存，GC频率等。在测试过程中可以通过jprofiler，Jconsle等工具去查看状态。查看每一次GC执行后，内存是否回收彻底。

如果回收前211554K，回收后1913K（回收前-回收后），回收数量209641K，Heap总量回收前350102K回收后140481K（回收前-回收后），回收总量209621K。这就表示有20k（新生区回收数量-堆区回收数量）没有被回收。分析到这里就可以看出每一次泄露的内存只有10几K，但是在大压力长时间的测试下，内存泄露还是很明显的。

而且当内存回收不彻底，会执行FULL GC，每执行一次FULL GC，系统就会暂停运行，如果一次FULL GC时间10ms，整个系统运行一周因为内存泄漏而多执行了FULL GC十万次，系统就多暂停1000S。对于内存泄漏去计算回收前后的堆内存有点麻烦，可以执行场景1个小时，开启jconsle，看他的GC情况，场景执行完成继续监控一个小时，看这个过程中是否还会有GC产生。如果有规律性的GC产生也需要注意看是否有内存泄漏。

当然还有其他的一些应用程序情况，如类方法速度慢，就需要测试人员和开发人员配合找原因了，或者用其他工具定位出具体的方法名。 还有就是服务器的后台错误日志了。

 

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

 

每秒通过事务数/TPS当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈

 

每秒点击次数通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

 

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

 

第一次缓冲时间细分(随时间变化))可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。

 

连接数当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高(事务响应时间将降低)