jmeter 之短板以及建议解决方案
随着JMeter的应用，发现JMeter的局限性越来越多，急需进一步扩展改进一 几百兆的sample 日志解析出现OutOfMemory
最近的几个项目都是Java sample 日志，应用都是高达300 tps的，而响应时间都在百毫秒级别，所以在 <60分钟的运行过程中，生成JMeter 采样日志到达几百兆。
用JMeter gui解析日志，多次出现OutOfMemory，不爽。
规避但不治本方法：
1) 放到>4G 内存的LINUX 机器上， 设置-Xmx2048m甚至更高启动JMeter.sh
2) 放到64位的java 版本上
3) 减少java sample运行时间或者次数，减少日志尺寸
4) 对要求长时间的场景，采用shell 方式启动-关闭jmeter-重命名生成日志 的方式减少日志尺寸
最根本方法：改写jmeter日志解析部分为NONE GUI,或者用C/c++效率更高的语言解析有规律日志
二 分布式多台监控机器
这个也不是jmeter 的长处。尤其是要求监控iowait%,netstat 连接数，NAS 上监控数据。
解决办法：
用loadrunner monitor+扩展DLL。
三 被测程序为client API
由于JMeter 运行消耗资源较大，无法清晰区分client api本身是否有短期对象、内存泄漏。
在确认Client api自身没有并发问题、内存泄漏、短期对象问题后，
可以client api内部加入一些度量数据输出到excel+结合jmeter获取更多的平均值、标准差等数据
四面向目标的场景控制
比如要求控制服务器的资源在一定负载下。如要求linux 机器load 接近5时，求解TPS为多少？
由于系统受到应用CACHE,OS CACHE,NAS CACHE 等影响，单纯采用JMeter 将耗费极大精力。
解决方法：
用java 多线程程序发起压力+另外线程检索/proc 目录数据视负载增加/减少压力线程数。同时将变化的线程数与资源负载输出到文件，将这些数据做趋势分析。
再用线程数应用在jmeter上 反馈验证 楼主经验很丰富哦
谢谢分享 楼主很强大，经验丰富的牛人呐，向楼主学习:lol 胡说八道
我怎么没遇到你说的几百兆的日志文件啊~~ 关注中 JMeter的使用必须二次开发
有问题很正常 就看公司是否有条件去做。 貌似二次开发的资源很少很少啊，对新手来说比较难，有没有什么介绍的入门的资料:handshake
回复 7# 的帖子
我个人认为 如果你对java开发熟悉进行jmeter定制开发 完全没问题 :L 不熟 第一个问题我也遇到过,不过在一定程度上已经是解决了.(其实JMeter的问题不在内存)第二个问题应该是作为性能测试的整体解决方案.JMeter本身是一个性能测试工具.可以对其做二次开发来满足一些解决方案或者寻求其他工具配合监控.(不想花钱总得花点力气和脑筋的)
第三个问题有点远,JMeter最初是为web service的性能测试作为开发目标的.现在功能在增加,但要做到通用也不是很快的事情.(不然LR也不会开价这么高了)
第四个问题的确是JMeter做不到的并且商业软件也不可能精确的做到,我们可以通过测试用例的合理化来达到性能评估的目的.(所谓条条道路通罗马) 很流行的工具的说
页:
[1]
