文章多数来自互联网,若有冒犯的地方,请朋友们说明下,我会及时删除该文章!
(六)性能测试从零开始——LoadRunner入门与提升
上一篇 /
下一篇 2011-04-19 10:27:44
/ 个人分类:LoadRunner
(六)性能测试从零开始——LoadRunner入门与提升
11.3.3 负载测试案例分析
1.某票单功能测试结果概要
表11-9 功能测试结果概要
在以上运行中,无失败或错误事务,但需要注意的是,100个并发用户在近4分钟内已经造成了750MB的流量,占用带宽3.1M/S。
在以上运行中,无失败或错误事务,但需要注意的是,Loadrunner显示已经顺利并发100个用户,并成功进行提交。但经过查阅后台数据,发现仅成功提交31个票单。经过反复排查,发现在100用户并发时,数据库出现死锁,报出信息如下:
信息:执行查询SQL语句时发生错误:[IBM][CLI Driver][DB2/AIX64] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "68". SQLSTATE=40001
[IBM][CLI Driver][DB2/AIX64] SQL0911N The current transaction has been rolled back because of a deadlock or timeout. Reason code "68". SQLSTATE=40001
2.虚拟用户数ramp趋势图
图11-12 虚拟用户数ramp趋势图
2.DB2 Server UNIX Resource趋势图
图11-13 DB2 Server UNIX Resource趋势图
图中浑色高位曲线为CPU Utilization(Unix Kernel Statistics)。与并发用户数趋势基本一致。
3.WebLogic监控图
WebLogic的ExecuteThreadTotalCount一直处于100的占用率,此处有调优空间。
图11-14 WebLogic监控图
4.JVM监控图
图11-15 JVM监控图
从图11-5可见,JVM的heap size随着压力的起伏而收放,可以判定本系统应该没有明显的内存泄漏问题。
5.DB2监控图
图11-16中高位曲线为total_sort_time,是排序时间,为986584,Total_sorts为33078。
图11-16 DB2监控图
排序时间为total_sort_time/total_sorts=986584/33078=30,花在排序上的时间过长。疑为不规范sql语句所致,有待排查。
图中最低位曲线为pool_index_read,是索引池的读取率,一直处于零,这是不正常的。经过排查,发现USERID.T_LP_GZP表包含80多个字段,仅建了7个索引,很有可能索引建得不合理,没有建在order by字段上。
收藏
举报
TAG: