loadrunner
软件界面
LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner能支持广泛的协议和技术，为您的特殊环境提供特殊的解决方案。[
性能测试。
软件测试工具中如何巧用LoadRunner的随机函数
LoadRunner有自带的随机函数，如果巧妙的加以采用，能解决一些看似很困难的实际问题。
一个项目的性能测试。与数据库直连，根据外部传入的SQL ID和SQL参数，从指定数据库中读取SQL模版，拼装成真实的SQL语句、执行，并将得到的结果放入缓存中。目的是减少数据库的压力。
该系统将支撑大量的SQL操作，性能自然成为备受关注的焦点之一。
由于它跟SQL语句相关，在真实环境下，同一时间可能执行着不同类型的SQL，即便是同一类型，其参数也各式各样。那么，怎样才能模拟出最符合实际情况的性能测试场景呢？
首先设计场景，即，在LoadRunner中按照比例随机取到某一类型的SQL，再随机传入参数给它，让最终的每条SQL都是随机生成，各不相同。
从场景中，可以看到，此处涉及双重随机。只采用loadruner的参数设置是无法实现的。此时需要想办法先按设定好的比例随机取到SQL，然后在每条SQL上随机取参数列表中的参数。
于是想到了loadrunner的随机函数。先实现随机取SQL ID，之后再在特定的SQL中随机取参数列表中的参数。
LoadRunner中，随机函数是rand()，它用来产生0到rand_max之间的随机整数。函数原型是
int rand ( void );
然而调用rand之前，必须给随机数产生一个随机种子。这个种子由srand()函数产生。其原型是
int srand ( seedTime );
采用上述两个函数，就能实现第一重随机了。具体脚本代码如下：
| //generate rand number int rNum = 0; srand(time(NULL)); rNum = rand() % 10; lr_output_message(”the number is :%d”,rNum); //print the current random number 生成随机数后，再按比例用if … else … 来取到各种类型的SQL，并给它们传参。具体脚本代码如下： //get certain SQL and random value if (rNum>=0 && rNum<2) { web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “, ”Resource=0″, ”RecContentType=text/html”, ”Referer=”, ”Snapshot=tn.inf”, “Mode=HTTP”, LAST); } … else if(rNum>=8 && rNum<10){ web_url(”test”, “URL=http://host_name:8080/interface?sqlId=sqlid_name2&value={random_para2} “, ”Resource=0″, ”RecContentType=text/html”, ”Referer=”, ”Snapshot=tn.inf”, “Mode=HTTP”, LAST); } else { rNum = 0; lr_output_message(”the number is :%d”,rNum); } |
注：sqlid_name是SQL ID名称；random_para是通过file方式实现的随机参数；tn是web_url函数的快照名称。
通过上面的脚本，实现了性能测试设计的场景。调试通过后，放入Controller中执行。实际执行过程中，Vuser将会按比例随机取到不同类型的SQL，并随机取到SQL中的参数，执行特定的SQL语句。
巧用LoadRunner的随机函数，能解决不少实际问题。[1]网络出现带宽瓶颈.同理若点击率/TPS曲线出现变化缓慢或者平坦,说明服务器开始出现.
3. 请求响应时间
Time to Last Byte
4. 每秒系统处理事务数
Transaction per second
5. 吞吐量
Throughout
6. CPU利用率
Processor / %Processor Time 好：70%
坏：85%
很差：90%+
7. 数据库操作消耗的CPU时间
Processor / %User Time 如果该值较大，可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器， Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间，此时可以考虑对数据库系统进行优化。
8. 核心态CPU平均利用率
Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统
9. 处理列队中的线程数
Processor / Processor Queue Length 如果该值保持不变(>=2)个并且%Processor Time 超过90%，那么可能存在处理器瓶颈。如果发现超过2，而处理器的利用率却一直很低，那么或许更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。
10. 文件系统缓存
Memory / Cache Bytes 50%的可用物理内存
11. 剩余的可用内存
Memory / Avaiable Mbytes 至少要有10% 的物理内存值
12. 每秒下载页数
Memory / pages/sec 好：无页交换
坏：CPU每秒10个页交换
很差：更多的页交换
13. 页面读取操作速率
Memory / page read/sec 如果页面读取操作速率很低，同时 % Disk Time 和 Avg.Disk Queue Length的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
14. 物理磁盘利用率
Physical Disk / %Disk Time 好：<30%
坏：<40%
很差：<50%+
15. 物理磁盘平均磁盘I/O队列长度
Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能，可增加磁盘
16. 网络吞吐量
Network Interface / Bytes Total/sec 判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽，结果应该小于50%
17. 数据高速缓存区命中率 命中率应大于0.90最好
18. 共享区库缓存区命中率 命中率应大于0.99
19. 监控 SGA 中字典缓冲区的命中率 命中率应大于0.85
20. 检测回滚段的争用 小于1%
21. 监控 SGA 中重做日志缓存区的命中率
应该小于1%
22. 监控内存和硬盘的排序比率 最好使它小于 10%[4]
-
参考资料：
-
扩展阅读：
- 1.一个真实项目的LoadRunner软件性能测试的数据分析 http://www.ltesting.net/html/10/n-167710.html
- 2.关于Loadrunner关联 http://www.ltesting.net/html/59/n-167259.html
2097
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
