性能测试实例讲解

1、Hundsun Technologies Inc. | 性能测试实例讲解性能测试实例讲解 Hundsun Technologies Inc. |运行场景前准备工作运行场景前准备工作1.测试目标2.测试用例3.独立性能测试环境（包括压力测试机在内）4.各服务器硬件配置5.各服务参数配置6.数据库基础数据量Hundsun Technologies Inc. |一、数据库一、数据库SQL效率导致瓶颈效率导致瓶颈Hundsun Technologies Inc. |数数米基金网拓扑图和硬件统计米基金网拓扑图和硬件统计序号名 称IP机器配置1.webloigc服务器2CPU：Int

2、el(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核内存：8G硬盘：400G网卡：千兆网卡操作系统：LINUX 64位1.tuxedo服务器1CPU：Intel(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核内存：8G硬盘：400G网卡：千兆网卡操作系统：LINUX 64位1.oracle服务器9CPU：Intel(R) Xeon(R) CPU E5-2407 0 2.20GHz 8核内存：16G硬盘：60G网卡：千兆网卡操作系统：LINUX 64位Hundsun Technologies Inc. |

3、数数米基金网性能测试参数配置米基金网性能测试参数配置Weblogic:-Xms5122m-Xmx5122m-XX:MaxPermSize=1024m-Dweblogic.threadpool.MinPoolSize=100-Dweblogic.threadpool.MaxPoolSize=500Tuxedo:MAXACCESSERS256MAXSERVERS100MAXSERVICES200Hundsun Technologies Inc. |数数米基金网交易记录查询米基金网交易记录查询LRLR结果结果在日志模式为info级别的前提下，模拟用户每隔5秒向后台发送交易记录查询请求（查询的时间段为

4、1年，返回结果为313条记录）。当Vuser14时，响应时间基本维持在8-10秒之间，TPS也达到最大将近1.2笔/秒；Vuser继续增加，TPS水平保持不变而响应时间大幅度上升，当Vuser=30时，响应时间达到了将近20秒。Hundsun Technologies Inc. |数数米基金网交易记录查询瓶颈分析米基金网交易记录查询瓶颈分析 我们可以看到得到的测试结果并不是很理想，那么接下来我们需要分析下到底瓶颈出现在哪里。 1. 我们将log级别设置为error级别查看性能是否有提升。测试结果是跟debug级别时的结果大致相同，所不同的只是weblogic服务器的磁盘IO从7%下降到了3%左

5、右。更改log级别对交易记录查询性能提升不大。Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析 2.我们继续观察服务器硬件在场景运行期间的性能情况。Weblogic服务器和tuxedo服务器硬件性能在场景运行期间表现正常，这里不再赘述，我们这里重点说明下oracle服务器的硬件性能情况：场景运行期间的CPU平均值维持在100%： Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析 3.可以看出数据库CPU压力过大可能是制约系统性能的瓶颈点，那么为什么数据库CPU压力

6、在TPS很低的情况下会如此之大？我们先看看应用服务层表现是否正常，weblogic的JVM堆内存在2G-3.5G之间波动，GC较正常，峰值线程为261个，加载类稳定在19239个，消耗的CPU在15%-20%之间。 Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析监控weblogic的热点发现92.6%的时间消耗在wait()方法上，追踪调用方法发现耗时主要在socket的read上： Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析 4. 我们先来看下ORACL

7、E数据库的AWR报告，DB Time很大，数据库很繁忙，这里我们从数据库服务器的硬件已经看出： Load profile和SGA的各种命中率都正常：Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析top 5 事件 CPU time是第一位： 有两条SQL语句执行数量明显大于其他SQL语句，占用了CPU总耗时的83.2%Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析我们发现调用直销查询服务返回有条数限制（这里限制为50条），所以返回313条记录要调用查询7次，造成

8、响应时间和oracle服务器的cpu资源大量被消耗。这两条SQL语句一个查条数，一个查数据，具体如下:可以看到其结构非常复杂，嵌套层数很多，且有大量嵌套循环，而且每次事务要查询7次，难怪每次查询的响应时间会这么长。 Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析那么我们是否可以采用分页显示呢？直销查询服务返回既然有50条的数限制，那么我们就模拟每次只查询50条记录的场景，即每次查询只调用一次后台SQL查询。测试结果是在无压力情况下，查询一次响应时间在1.8-2秒左右；当模拟用户数达到40个时，后台处理速度达到最大3笔/秒，响应

9、时间在6秒左右，随着模拟用户继续增加处理速度基本不变，响应时间大幅度增加。后台weblogic的CPU压力平均22.3%左右，tuxedo服务器CPU压力平均值为6.2%，数据库服务器CPU压力平均值为47%左右。可以看到每次查询数量减小后，无论响应时间和服务器CPU压力等性能提升都比较明显。查询修改为分页显示会提高不少性能。 Hundsun Technologies Inc. |数米基金网交易记录查询瓶颈分析数米基金网交易记录查询瓶颈分析优化建议：1.从短期来看，我们可以在硬件上设置数据库集群来缓解数据库服务器的压力，增大可以接受的访问系统的人数；建立缓存服务来减少对历史数据的查询次数；查询

10、修改为分页显示也会提高不少性能。2.要从根本上优化此测试用例的性能，症结还是在oracleAWR报告部分提到的两条SQL，它们被多次调用，而且这两条SQL结构非常复杂，嵌套层数很多，建议最好请DBA协助对此SQL进行改进。 Hundsun Technologies Inc. |二二、数据库行锁导致瓶颈、数据库行锁导致瓶颈Hundsun Technologies Inc. |多金融证券理财认购多金融证券理财认购LRLR结果结果 Loadrunner模拟70个虚拟用户无等待时间向后台发送认购请求，场景运行期间后台TPS最大690笔/秒，平均650笔/秒，平均每笔认购的响应时间为0.1秒。如果再增大

11、压力，后台的TPS不会再增大，说明后台的TPS已经达到最大的处理能力。Hundsun Technologies Inc. |多金融证券理财认购瓶颈分析多金融证券理财认购瓶颈分析 以下是场景运行期间各服务器的硬件性能统计。单从硬件性能统计来看，硬件表现都很正常，不存在瓶颈。Hundsun Technologies Inc. |多金融证券理财认购瓶颈分析多金融证券理财认购瓶颈分析 我们更进一步去看各服务是否存在瓶颈，场景运行期间我们通过HSADMIN监控AS和LS的接收和应答包，发现无请求积压：Hundsun Technologies Inc. |多金融证券理财认购瓶颈分析多金融证券理财认购瓶颈分

12、析 进而我们继续观察数据库，通过ORACLE AWR报告发现数据库TOP5事件中行锁占用了数据库运行时间的82%，已经存在很严重的行锁事件：而通过行锁事件统计表来看基本所有的行锁都发生在prodcontrol表中：Hundsun Technologies Inc. |多金融证券理财认购瓶颈分析多金融证券理财认购瓶颈分析 进而我们继续观察数据库，通过ORACLE AWR报告发现数据库TOP5事件中行锁占用了数据库运行时间的82%，已经存在很严重的行锁事件：而通过行锁事件统计表来看基本所有的行锁都发生在prodcontrol表中：Hundsun Technologies Inc. |多金融证券理财

13、认购瓶颈分析多金融证券理财认购瓶颈分析 而通过TOP SQL统计表我们发现耗时的SQL语句也正是关于prodcontrol表的查询语句：SELECT UP_LIMITED, CURR_LIMITED FROM PRODCONTROL A WHERE A.PROD_CODE = :B3 AND A.PRODTA_NO = :B2 AND A.ORGAN_FLAG =! AND A.ENTRUST_WAY =! AND (A.BUSINESS_FLAG =:B1 ) FOR UPDATEHundsun Technologies Inc. |多金融证券理财认购瓶颈分析多金融证券理财认购瓶颈分析 我们

14、知道for update语句的效果相当于启动了一个会话级别的事务，在对应的数据表上加入一个数据表级共享锁，同时在对应的数据行中加入独占锁；而如果此时有另一个会话想获取对应数据行的独占权限，都会block在那里等待锁的释放。这也是为什么场景运行期间数据库行锁事件占了TOP事件的第一位，而这也就是本功能点的瓶颈所在了。Hundsun Technologies Inc. |三、服务内存泄露导致瓶颈三、服务内存泄露导致瓶颈Hundsun Technologies Inc. |证证通开放平台架构通开放平台架构 Hundsun Technologies Inc. |证通开放平台访问首页证通开放平台访问首页

15、LRLR结果结果 Loadrunner模拟50个虚拟用户无等待时间向后台发送访问首页请求，场景运行期间后台TPS达到750笔/秒，平均每笔事务的响应时间为0.065秒。如果再增大压力，后台的TPS不会再增大而响应时间在不断增大，说明后台的TPS已经达到最大的处理能力。当场景运行至6分30秒时，场景的TPS突然降低至几笔/秒，响应时间猛增至5秒左右。Hundsun Technologies Inc. |证通开放平台访问首页瓶颈证通开放平台访问首页瓶颈分析分析以下是场景运行期间各服务器的硬件性能统计。单从硬件性能统计来看，门户服务器的CPU压力基本达到极限，这也是为什么访问首页功能点的TPS在达到750笔/秒后不再上升的原因。但是在场景运行一段时间后，TPS突然降低至几笔/秒，单从硬件性能表现上还无法查明原因。 Hundsun Technologies Inc. |证通开放平台访问首页瓶颈证通开放平台访问首页瓶颈分析分析我们再看TOMCAT服务的表现，CPU压力占用服务器CPU90%左右；堆内存消耗从初始化开始的500MB随着场景增大，最大达到堆内存的最