比较完常见后置处理器的性能以后，又顺便比较了下Groovy和BeanShellhtml
2者都是基于JVM的脚本语言，2者都能直接用Java的语法和类库java
这些国外网站都推荐用Groovy：shell
http://jmeter.apache.org/usermanual/best-practices.html数据库
http://www.ubik-ingenierie.com/blog/magento-performance-toolkit-and-jmeter-best-practices/apache
https://blazemeter.com/blog/beanshell-vs-jsr223-vs-java-jmeter-scripting-its-performancepost
由于JMeter支持的一堆脚本语言里，只有它有预编译性能
关于jmeter的中文网站里提到groovy的不多，不知有人比较过预编译带来的速度提高有多大没测试
正好闲着来试一下网站
环境：jmeter 2.1三、JDK 1.8u7三、JVM参数历来没动过、win 10 prospa
在项目里我就是直接上Groovy的，能够用现成的脚原本测试 ：）
生成随机手机号的脚本，注释就不截了
提取到另外一个脚本的公用方法，无关的也不截了
为了效率，用了静态编译（性能比较见这里）
每当这脚本有改动，要用groovyc从新编译（生成的class文件跟java同样，用jad反编译就能看到java代码）
其余脚本引用的就是这个class文件
scripts目录加入了jmeter的properties文件里，因此哪里都能引用到这文件
为了测试，建立个beanshell脚本文件，就是文本文档把后缀改成.bsh
不知道beanshell风格是怎样，直接套java语法
如今2边作的事是同样的，beanshell脚本还少几回调用
咱们进JMeter，建好以下的测试计划：
暂时用不着的组件先ctrl + t禁用掉
先测试最简单的hello world，采样器配置以下：
* 要先下载安装groovy，安装目录下找到embeddable文件夹，把groovy-all-2.x.x.jar拷到jmeter安装目录下的lib文件夹下
而后重启jmeter才能在jsr223的菜单里看到groovy的选项
* cache key随便写点什么，保证惟一就行。直接在下面写脚本时须要写上cache key才有预编译
重启jmeter，运行测试1次，看到jmeter的命令行窗口里有了正确的输出
然而2边都慢得离谱，尤为是groovy慢得吓死人
清掉记录再来，预热以后好看点了
以后n次都差很少，groovy历来没低于10毫秒
一个hello world都比beanshell慢3~十几倍，这能用吗？
咱们看看拿正经的脚本，跑足够多的次数会怎样
首先2个采样器的设置以下：
就是填脚本文件的路径和传个变量名给脚本，没啥特别
值得注意的是groovy只要使用了外部脚本文件就有预编译，这时不用填cache key
用1个线程循环1次调试经过
修改线程组设置为：10个线程，1秒集结（0.1秒来1个），持续60秒，无启动延迟
ctrl + t禁用无关的组件（变灰那些），注意关掉全部监听器，由于接下来要用命令行运行，留着它们会拖累吞吐率
关掉界面，用命令行跑测试，结果以下：
BeanShell
再进界面改为用jsr223采样器，等爆表的cpu内存占用率回落后再跑，结果以下：
Groovy
留意summary + 的那几行，groovy一开始特别慢，请求耗时的最大值吓死人，以后减小了10倍，最终结果就是
3倍速！
没什么好说的，选Groovy就对了（并且Gradle和Jenkins也用获得它）
PS：
上述测试保存报告文件为csv格式，使用以下设置
大部分数据在这里都用不上，关到剩下最精简的几个
若是用一般的设置，报告文件估计要大5倍不止
就剩4列，彷佛无法再少了
留意耗时最长的通常都是前几回，以后就快了，统计时忽略开头某段时间的数据就好
又PS：
上面的生成手机号的脚本是给接口测试用的，性能测试就别当场生成了
先搞好几十万个塞进数据库或csv文件慢慢用吧