loadrunner的不足与jmeter用武之地
我们购买了LoadRunner 8.1 作为性能测试主流工具,商业工具确实用的蛮好的,在部门层面推行顺利。结合实践,发现有几点相当不错:
1) LoadRunner controller运行稳定
2) 支持多个load generator 一起施加压力
3) 监控指标相对齐全
4) 性能测试结果颗粒细致
5) 预留有性能结果在monitor上的api 接口
...
但LoadRunner是否足够完美了呢?答案:NO
1) 对汉语的编码支持问题:utf-8/gbk设置导致有时仅用英文作web_reg_find的check point
2) LoadRunner 8.1 Udp方式监控unix资源导致有断续, 呵呵,改天要电话咨询下HP有无补丁。
(LR 8.0有的)
3) 有时应用vugen 录制/回放异常退出程序
4) 最为诟病的:昂贵
5) 支持jboss/tomcat/mysql等的应用性能数据需要自己实现,实际上监控linux也无可用内存、iowait%、网络流量等指标
...
我们把更多眼光关注开源社区,评估opensta、jmeter、webload...。 最终选取与公司主流技术平台( java+apache2+ jboss4.2 +oracle9i/10g + redhat linux)一致的jmeter做一个补充。
对于Jmeter最为关键的几步:
1) 分析性能测试结果和loadrunner不同的原因
2) jmeter 产生压力的稳定性以及原理
3) 监控扩展能力。 linux+oracle9i+jboss+mod_jk 等这些需要支持,呵呵,否则很可能需要手工收集各个平台性能数据,造成效率低下
4) jmeter脚本调试能力,支持参数化、关联、检查点、http协议自主控制(超时、cookie、http头、是否下载non-html资源)等 不错。可以列出一个表来。 不错。可以列出一个表来。 jmeter是开源的吧,是否可以看到由scripts转变成request的内部过程?
其实我觉得LZ少说了LR的一个严重不足——因为非开源产品,LR的scripts与request之间是如何转换的,这个过程中是否有失真?
我在学习LR 时就在想,如果能自定义函数然后写自己需要的request该多好啊,就等于完全控制了request和response,完全控制了服务端和客户端的通信过程。
希望能更多介绍jmeter的内容,LZ继续努力吧!:victory:
jmeter的使用
可以考虑与badboy的结合使用,单独的jmeter很难说得上是有效率的工具。 1 jmeter2.3.1上有 http代理服务器,可以完成录制功能2 LR的scripts与request之间是如何转换的?
这个问题完全可以用嗅探器以及结合服务器的访问日志或者tcpdump侦听到的。呵呵,我确信没有问题 对于web测试,lr是首选,毕竟jmeter用java写的,效率是个问题,尤其对于模拟大并发的时候,socket也是个问题
我们主要用jmeter+junit做一些引擎测试、核心模块功能
也推荐去了解一下Grinder,和jmeter差不多,但更灵活 原帖由 tacy_lee 于 2008-6-22 16:40 发表 http://bbs.51testing.com/images/common/back.gif
对于web测试,lr是首选,毕竟jmeter用java写的,效率是个问题,尤其对于模拟大并发的时候,socket也是个问题
我们主要用jmeter+junit做一些引擎测试、核心模块功能
也推荐去了解一下Grinder,和jmeter差不多, ...
java写的?那执行效率可以保证吗? 挺好! :victory: :victory: :victory:
页:
[1]