一、比较测试时间和实际运行时间
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
性能测试分析
猜你喜欢
转载自yanzhu2011.iteye.com/blog/1825398
今日推荐
周排行