我是一個用慣Loadrunner的人，由於Loadrunner過於重量級，不方便在雲端部署和使用，所以平常在這方面只能選擇Jmeter，Jmeter的開源性和輕量化是我最喜歡的地方，但是Jmeter的腳本開發模式是我最不喜歡的地方：jmx腳本對應的XML格式太不直觀，不方便維護和管理，代碼調試也不方便（對於我們這些不願意依賴於腳本錄製的人來說，這點很重要），另外不喜歡的就是Jmeter的性能和穩定性，即使用了Non-GUI + 分佈式壓測的模式，Master節點的承受能力也不如Loadrunner。
所以我真的比較傾向於找一款既能像Loadrunner那樣高性能高穩定性，代碼維護管理自如，又能像Jmeter那樣輕量級的、高擴展性的測試工具。目前來看好像不存在這種工具，但是有一款性能測試工具叫Gatling，與Jmeter進行分析比較了一下，覺得它很有潛力，興許哪一天，它借鑑了Jmeter的一些優點，就達到了我的要求，或者Jmeter借鑑一下它，做個翻天腹地的改造，那也未嘗不可。
對於Gatling的優點網上也總結了很多，我也不多說，但是光從測試場景配置上來說，Gatling就不輸Loadrunner，拿例子來說明：
setUp(
scn.inject(
nothingFor(4 seconds), // 場景1
atOnceUsers(10), // 場景2
rampUsers(10) over(5 seconds), // 場景3
constantUsersPerSec(20) during(15 seconds), // 場景4
constantUsersPerSec(20) during(15 seconds) randomized, // 場景5
rampUsersPerSec(10) to(20) during(10 minutes), // 場景6
rampUsersPerSec(10) to(20) during(10 minutes) randomized, // 場景7
splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(10 seconds), // 場景8
splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(atOnceUsers(30)), // 場景9
heavisideUsers(100) over(20 seconds) // 場景10
).protocols(httpConf)
) 以上代碼包含了10個場景的例子：
1. nothingFor(4 seconds)
在指定的時間段(4 seconds)內什麼都不幹
2. atOnceUsers(10)
一次模擬的用戶數量(10)。
3. rampUsers(10) over(5 seconds)
在指定的時間段(5 seconds)內逐漸增加用戶數到指定的數量(10)。
4. constantUsersPerSec(10) during(20 seconds)
以固定的速度模擬用戶，指定每秒模擬的用戶數(10)，指定模擬測試時間長度(20 seconds)。
5. constantUsersPerSec(10) during(20 seconds) randomized
以固定的速度模擬用戶，指定每秒模擬的用戶數(10)，指定模擬時間段(20 seconds)。用戶數將在隨機被隨機模擬（毫秒級別）。
6. rampUsersPerSec(10) to (20) during(20 seconds)
在指定的時間(20 seconds)內，使每秒模擬的用戶從數量1(10)逐漸增加到數量2(20)，速度勻速。
7. rampUsersPerSec(10) to (20) during(20 seconds) randomized
在指定的時間(20 seconds)內，使每秒模擬的用戶從數量1(10)增加到數量2(20)，速度隨機。
8. splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(10 seconds)
反覆執行所定義的模擬步驟(rampUsers(10) over(10 seconds))，每次暫停指定的時間(10 seconds)，直到總數達到指定的數量(100)
9. splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(atOnceUsers(30))
反覆依次執行所定義的模擬步驟1(rampUsers(10) over(10 seconds))和模擬步驟2(atOnceUsers(30))，直到總數達到指定的數量(100)左右
10. heavisideUsers(100) over(10 seconds)
在指定的時間(10 seconds)內使用類似單位階躍函數的方法逐漸增加模擬併發的用戶，直到總數達到指定的數量(100).簡單說就是每秒併發用戶數遞增。
就拿場景8來說，可以製造一種波浪型壓力，非常適合模擬一種脈衝式的壓力測試或是某類穩定性測試（壓力按波峯波谷有規律的分佈），如下所示：
------------------------------------------------------------------------------------------------------------------
雖然Gatling很讓我們驚奇，但就目前來說，還遠沒有達到我們的最佳選擇，不過研究它已經非常有必要了，畢竟一個好工具的普及不是一天兩天的事。Jmeter有那麼多不如意的地方，但我們還得繼續用呀，現在腳本的易維護性方面還不是最重要的問題，最緊迫的是如何對Jmeter進行減負，以實現穩定超高併發測試，目前只能考慮以下的方式進行：
減負一，優化監聽（GUI模式，儘量不考慮）
1.“查看結果樹”，需要勾選“僅日誌錯誤”，這樣只會保存錯誤日誌到內存，數據不會多。如果保存所有，那麼會保存每個請求信息和相關信息，而且這些數據都是保存到jvm內存的，且常駐數據無法回收，上萬十萬大量請求很快就會壓垮jmeter。
2.“聚合報告”中小並（100以內）發可以保留；高併發去掉，添加“Simple Data Writer”且保存csv格式數據。“聚合報告”是非常消耗cpu的。
3.其他監聽組件可以都去掉，測試完後通過保存的結果，線下生成圖表報告
減負二，優化監聽（Non-GUI命令行模式）
1.“查看結果樹”，需要勾選“僅日誌錯誤”，需要設置路徑，保存錯誤信息到文件，並且保存所有信息（點擊Configure，勾選所有非CSV選項）
2.“聚合報告”命令行下無效
3. 其他監聽組件可以都去掉，基本在Non-GUI下無效
減負三，結果文件優化
1. 結果數據一定要保存爲CSV格式（比起xml格式，每條數據會少很多）（可以用Non-GUI命令指定csv日誌保存）
2.“查看結果樹”保存的錯誤信息要保存爲xml，可以保存完整結果信息，方便錯誤分析
減負四，如果要超高併發建議不要直接使用分佈式壓測
1. jmeter分佈部署只是緩解問題，沒根本解決問題，高併發時master機器承受的壓力很大，形成單點，無法在高併發時提供穩定負載
2. 數據會寫可能丟失
3. 解決方法：需要手工運行slave，或利用jenkins同時觸發多臺slave
減負五，再強調一下，建議用Non-GUI命令行模式運行，並且選擇Linux環境運行Jmeter也是很有必要的
1. 用Non-GUI運行jmeter生成csv報告，但別輸出html報告（需要高jvm內存來完成，所以分成兩步進行）
2. 修改jmeter的jvm內存（建議物理內存的一半，HEAP的xms和xmx，1G的csv報告建議對應2G的xmx大小），用高jvm內存來轉換csv報告至html報告（內存不夠就換機器來轉換報告）
減負六，可以選擇用Jmeter + Grafana + InfluxDB的方式，來代替報告文件的生成，參考我的另一篇文章《關於Jmeter長時間壓測的可視化監控報告》
1. 將Jmeter分佈式集羣去中心化，Master節點不再負責收集和處理測試數據，只負責調度slave節點
2. 支持多Master-slave，形成多路Jmeter測試集羣（利用Jenkins或其他調度工具同時觸發調度測試）