loadrunner的不足与jmeter用武之地

liangjz

我们购买了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资源)等

Zee

不错。可以列出一个表来。

Zee

不错。可以列出一个表来。

kursk

jmeter是开源的吧，是否可以看到由scripts转变成request的内部过程?

其实我觉得LZ少说了LR的一个严重不足——因为非开源产品，LR的scripts与request之间是如何转换的，这个过程中是否有失真?

我在学习LR 时就在想，如果能自定义函数然后写自己需要的request该多好啊，就等于完全控制了request和response，完全控制了服务端和客户端的通信过程。

希望能更多介绍jmeter的内容，LZ继续努力吧！

ebuluo

可以考虑与badboy的结合使用，单独的jmeter很难说得上是有效率的工具。

liangjz

1 jmeter2.3.1上有 http代理服务器，可以完成录制功能
2 LR的scripts与request之间是如何转换的？

这个问题完全可以用嗅探器以及结合服务器的访问日志或者tcpdump侦听到的。呵呵，我确信没有问题

tacy_lee

对于web测试，lr是首选，毕竟jmeter用java写的，效率是个问题，尤其对于模拟大并发的时候，socket也是个问题

我们主要用jmeter+junit做一些引擎测试、核心模块功能

也推荐去了解一下Grinder，和jmeter差不多，但更灵活

kursk

原帖由 tacy_lee 于 2008-6-22 16:40 发表
对于web测试，lr是首选，毕竟jmeter用java写的，效率是个问题，尤其对于模拟大并发的时候，socket也是个问题

我们主要用jmeter+junit做一些引擎测试、核心模块功能

也推荐去了解一下Grinder，和jmeter差不多， ...

java写的?那执行效率可以保证吗?

fish_yy

挺好！

hmilyjch