LoadRunner压力测试和可伸缩性_笔记解析.doc

LoadRunner相关过程: 优化整个项目的常用方法: 升级硬件:4G内存,4核cpu 提高Tomcat线程池数量。 在server.xml文件里加入Connecto maxThreads=1000 minSpareThreads=100 maxIdleTime=60000 提高Tomcat和Jboss的JVM内存。 Tomcat/catalina文件中: JAVA_OPTS=-Xms512m -Xmx1024m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m Jboss/run.conf文件中: JAVA_OPTS=$JAVA_OPTS –Xms1024m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:MaxNewSize=256m -Dfile.encoding=GBK 如果是访问数据库慢，那么修改数据库连接池的数量 LR并发测试用户数为100时，按20%来计算,那么实际能容纳的用户数为2w 对于高用户还是必须使用集群/分布式,对于高密集计算(响应时间长的方法)就必须使用并行计算,如使用多线程和hadoop Loadrunner实践 负载测试流程是什么？ 负载测试通常由五个阶段组成：计划、脚本创建、场景定义、场景执行和结果 分析。 LoadRunner 最重要的组件 VuGen、Controller 和 Analysis ,用来创建 并运行您自己的测试，以及分析测试结果。 说明: 1,VuGen用来生成脚本。以及测试脚本正确性。 2,Controller利用1产生的脚本进行运行,一边运行一边修改脚本如加入事务,集合点(并发)等。然后再次运行脚本,最终生成曲线图和数据等报告。 (逐渐负载并发用户数量等或在脚本里手动修改业务执行条件,也可再次执行start record) 3,analysis利用2生成的报告，可以进一步来分析结果，找出系统瓶颈,进行优化。 图解: 1)vuGen如下图 特别要注意:只有IE6以下才支持。否则action里面没有生成脚本内容，recording也没有产生events!!无法进行测试了!! 所有必要时修改默认加载的浏览器:如下图(脚本为单协议时) 以下是负载测试, 在某个event前后加入事务点，作为单一事务。还可以在某个event前加入集合点,让所有用户都到达这个集合点，才同时并发访问后面的event。 Controller 以下选择think time，可以减少思考时间。以及输入了并发用户数量。 运行后的结果: 联机测试: 利用联机时,远程被联机的机子必须把LR的后台服务开启来。如 3) Analysis 你真的明白什么是可伸缩性吗？ 2008-06-12 14:08 可伸缩性，简单来说，是以更大的规模来做你现在所做的事。伸展一个Web应用的规模在于让更多的人使用你的程序。如果你没法找出方法在伸展规模的同时提高 性能，没关系。而且只要你可以伸展规模来处理更大数量的用户，那么有几个单点故障（single point of failure）也没关系。我们在面对规模伸展的时候有两个选择： 纵向的可伸缩性——在同一个逻辑单元内增加资源来提高处理能力。这样的例子包括在现有服务器上增加CPU，或者在现有的RAID/SAN存储中增加硬盘来提高存储量。横向的可伸缩性——增加更多逻辑单元的资源，并令它们像是一个单元一样工作。大多数集群方案、分布式文件系统、负载平衡都是在帮助你提高横向的可伸缩性。架构师们都在为达到线性的可伸缩性而挣扎，目的是让系统产出的增长与系统中投入资源的增长保持稳定的比率。然而，增加资源会导致一般耗费（overhead）的额外增长，因此难以达到线性的可伸缩性。Royans将之称为“伸缩性因子”，并用它来区分各种类型的伸缩能力： 如果在你扩大规模的时候伸缩性因子保持为常数，这种叫做线性伸缩性。 但很可能有些组件并不像其他组件那么适应规模的增长。小于1.0的伸缩性因子叫做次线性伸缩性。 话说回来，也可能因为增加更多组件而获得更佳的性能（在RAID系统中跨多个磁盘的I/O，当磁盘越多，性能越好）。这种叫做超线性伸缩性 。 如果应用程序没有专门为可伸缩性而设计，有可能当规模扩大的时候情况会变糟。这种称为负伸缩性。 跟软件开发中的许多事物一样，这里也没有适合一切情形的银弹可以解决你的伸缩性问题。Royans建议说，“如果你急切需要可伸缩性，向纵向发展可能是最容易的”，但注意“不幸的是纵向伸展会随着你的规模增长而越来越昂贵”，而且“无穷的横向线性伸缩性只是难以达到，而无穷的纵向伸缩性绝不可能”。