【转】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上 反馈验证。