【JMeter】Groovy和BeanShell脚本的性能比较
比较完常见后置处理器的性能之后，又顺便比较了下Groovy和BeanShell
2者都是基于JVM的脚本语言，2者都能直接用Java的语法和类库
这些国外网站都推荐用Groovy：
http://jmeter.apache.org/usermanual/best-practices.html
http://www.ubik-ingenierie.com/blog/magento-performance-toolkit-and-jmeter-best-practices/
https://blazemeter.com/blog/beanshell-vs-jsr223-vs-java-jmeter-scripting-its-performance
因为JMeter支持的一堆脚本语言里，只有它有预编译
关于jmeter的中文网站里提到groovy的很少，不知有人比较过预编译带来的速度提升有多大没
正好闲着来试一下
环境：jmeter 2.13、JDK 1.8u73、JVM参数从来没动过、win 10 pro
在项目里我就是直接上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文件慢慢用吧
