前幾天看了這篇文章 JMeter – Response Data Extractors – Comparison ，結論有點嚇人
用了css提取器吞吐率降到不足1/15？！按作者結論最快的正則提取器也降到1/5？
如果真是那樣那沒法用了，就好像測水溫，溫度計一插下去降了80度那還測個毛……
讓我覺得奇怪的是，作者沒有放出每個提取器里寫了什么，為啥用一段XML的報文能測這么多提取器
實驗了一下發現，作者的測試方法就是提取器里什么都不寫
當且僅當什么都沒寫時，作者的結論才是正確的……
但如果放到更貼近實際的場景里測試，會得出完全不一樣的結論：
這些提取器在什么都沒寫時，比實際做了什么還慢得多，導致這么嚇人的測試結果
下面來個正經點的測試，按不同返回類型比較提取器
環境：jmeter 2.13、JDK 1.8u73、JVM參數從來沒動過、win 10 pro
測試計划如下：
先用單線程單循環調試，調試采樣器和查看結果樹都打開
事前准備
所有dummy sampler都設成沒有延時
請求數據不用改，響應數據分別設置：
xml跟那文章的作者一樣貼這個 http://www.w3schools.com/xml/cd_catalog.xml
html隨便來個google地圖的示例
json用這里面的 http://goessner.net/articles/JsonPath/
紅框圈出的是分別想提取的數據：
設置好各提取器，調試，發現xpath提取器報錯了
看看dummy sampler里的html，發現是 & 符號搞鬼，改成url編碼 &
再試，還有錯
把async和defer改成符合xhtml規范，搞定
調試通過后的各提取器設置如下：
調試結果如下：
接下來修改各個線程組設置：
一律設成10線程，1秒集結（即每隔0.1秒來1個），持續60秒，沒啟動延遲。跟那文章作者的設置保持一致
（開始和結束時間是自動生成的，不用管，設了持續時間它們就用不上了）
最后選中用不着的組件，按ctrl + t禁用掉（就是圖中變灰那些），就可以開始實際測試了
圖有點多，測試過程及結果留到下一篇放出