比較完常見后置處理器的性能之后，又順便比較了下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文件慢慢用吧