随着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上 反馈验证。