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