比较完常见后置处理器的性能之后,又顺便比较了下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文件慢慢用吧