(六)性能测试从零开始——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字段上。