性能测试分析

一、比较测试时间和实际运行时间
eg、设置了运行时间是30分钟，但是，实际相差太大，实际运行的时间只有几分钟，这可能是什么原因导致没有持续运行设定的时间长度？
    打印出业务处理时间，统计实际运行总时间，分析等待、间隔时间等


二、nmon分析
1、nmon分析查看
  1）CPU： 16个CPU使用率都超过了95%以上，这个值说明你的CPU已经达到极限值，分析点：那个功能引起耗费CPU资源，哪个部分耗费时间比较长，建议将系统的日志打印出来，进一步分析，进而定位到代码或是函数级别
  2）mem
      cached+memfree+buffers >7G 内存应该没有问题
2、loadrunner oracle分析
1）SQL语句：
    查询出比较耗费资源的SQL语句
2）监控日志中 opened  cursors current
       打开的游标平均值在 1641 ，这值是不是过大了，过大了说明你的SQL语句可能执行过慢的。游标一直没有得到释放。
3）oracle 表索引
    检索的功能，查询的表基本上是固定的，查看一下索引是否合理的。
4）表数据量大小
    建议你分析一下oracle现在表的数据量是否过大，最好的数据是依据线上的数据库的数据量分析


三.服务器资源监控指标

　　(目前通过top监察)

　　内存：

　　Linux资源监控中指标内存页交换速率(Paging rate)，如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

　　实际测试中，当并发点击数出现突然剧增前后，内存的PR 值则居高25不下。说明目前测试的系统中内存存在瓶颈!

　　内存资源成为系统性能的瓶颈的征兆:

　　很高的换页率(high pageout rate);

　　进程进入不活动状态;

　　交换区所有磁盘的活动次数可高;

　　可高的全局系统CPU利用率;

　　内存不够出错(out of memory errors)

　　处理器：

　　Linux资源监控中指标CPU占用率持续超过80%(对该值的要求，根据具体应用和机器配置而要求不同，有资料表明95%)，表明瓶颈是CPU。

　　实际测试中，当并发点技数出现突然增加前后，cpu的占用率持续保持在86%以上!

　　说明，目前系统用应用的cpu也是测试的瓶颈!

　　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)

　　四.数据库服务器

　　数据库服务器目前测试观察，当web服务器点击率增大时，观察mysql数据库的最大连接数，仍未超过系统设置的最大连接数。所以，暂时未发现数据库的瓶颈!

　　五.结论

　　以上报告分析中的数据、图标均来自同一次测试。是在平时测试中挑出的一次现象比较明显，比较利于观察的作为分析案例。

　　根据以上综合分析，当前测试环境下，当应用系统产生最大533.667的并发压力。平均负载压力114.352。根据分析，用户在4个小时的时候，并发数迅速增加前后的值在400左右!分析结果跟实际测试的硬件环境以及测试脚本有一定关系。同时，测试服务器的硬件配置和实际服务器的配置还有一定的差距!
参考：http://bbs.51testing.com/thread-547806-1-1.html
http://tech.chinaunix.net/a2009/0602/581/000000581480_1.shtml