以下內容為360QA服務端效能專項團隊結合專案實踐，對團隊中當前應用的六款服務端壓力測試工具Loadrunner、Jmeter、SpirentAvalanche、Siege、Tsung、Locust進行分析對比。

● 六款工具特點對比

● 實際案例選型分析

【場景1】

業務介面使用標準HTTP互動json型別資料，該介面承載多使用者併發互動請求，測試預期為100併發使用者，500TPS的業務處理能力，每使用者測試指令碼事務邏輯：

• http get url_init，獲取到sid;

• httppost(username.password,sid)  url_login,通過認證後獲取到token；

• http post(token,search_args)  url_search,得到list型別的[item1,item2…..itemN];

• http post(token, [item1,item2…..itemN])url_get_item_result，得到每個item後臺查詢後的結果資料，每個item的返回有3種狀態，ok+data/error/wait

• 根據上一個請求的結果，對所有ok/error狀態的item進行統計計數，對wait狀態的item需要重新發起post請求結果(post時需重新組裝所有wait狀態的item到新[……itemN]列表)，直到所有item狀態為ok或error。

【選型分析】六款壓測工具都可以在單機環境下滿足本場景壓力需求，工具選型的關鍵點在業務場景的覆蓋上，特分析如下：

• siege一類工具，只能進行簡單的協議互動而不滿足測試需求；

• Tsung，受限於XML格式的指令碼語法能力約束，不能實現一些基本的程式設計邏輯，比如在for迴圈中通過break跳出迴圈，根據條件重組列表資料結構等，只能通過指令碼中引用erlang語句或編寫erlang擴充套件庫的方式來實現，考慮到這樣實現對Tsung XML指令碼語法體系的未知影響以及erlang語言開發的成本，tsung對於一些互動邏輯較複雜的測試場景還是不推薦選用的；

其他幾款工具，loadrunner、jmeter和locust由於分別使用c、java和python作為指令碼語言，所以實現這類互動邏輯的指令碼程式設計實現比較容易，可以根據自己熟悉的語言選擇工具。

【場景2】

業務介面為EAP-MD5互動及加密方式的radius協議，用於提供nas裝置(通常為802.1x交換機或閘道器裝置)做802.1X 使用者准入認證，測試需求為模擬nas裝置與業務介面做大併發的radius認證互動，得到業務介面處理認證請求處理能力及請求成功率/超時率統計，測試預期為支援100個nas裝置(併發使用者),2000qps的認證請求處理能力。

【選型分析】滿足該需求的首選工具是avalanche，完整支援EAP-MD5型別的RADIUS協議，且單口效能遠高於測試需求。由於avalanche為商用硬體平臺，成本較高，如果使用純軟體實現，對幾款工具進行開發擴充套件的成本分析如下：

• loadrunner支援c/c++動態庫擴充套件，可以基於開源的freeradius程式碼(純c)編寫動態庫來擴充套件loadrunner對eap-md5 RADIUS的支援，需要注意的是freeradius只支援linux gcc編譯，所以只能擴充套件linux版本的LR-LoadGenerate的.so庫。

• jmeter用標準java進行擴充套件，可以基於開源的Jradius(freeradius的java實現)程式碼編寫類庫來擴充套件jmeter對eap-md5 RADIUS的支援。

• tsung使用erlang語言來擴充套件，對於當前需求，erlang沒有radius的eap-md5實現，鑑於erlang語言的熟練程度，自己實現的成本太高，所以排除tsung工具。

• locust使用python語言進行擴充套件，可以使用pyrad庫來實現radius協議，但是pyrad原生沒有對eap-md5的支援，需要自己通過eap和md5庫來做實現，鑑於python的低成本開發，實現比較容易，但是經過對比測試，python的eap-md5 radius相對c和java版本，效能下降較大，通過locust在單機測試很難達到測試的效能指標，所以排除了locust工具。

綜合幾款工具的擴充套件能力及成本，最終確定了loadrunner和jmeter可以滿足當前需求，最終選型取決於c/java語言的開發熟練度。

【場景3】

業務介面使用標準HTTP get/post互動，介面互動簡單，只需要判斷每個請求後伺服器應答的http return code是否為200，由於服務端為叢集架構，需要的測試壓力較大，預期為50萬併發使用者，150萬qps。

【選型分析】對於這種弱互動的測試場景，所有工具都可以滿足需求，在測試資源成本角度考慮，loadrunner、jmeter、tsung、locust需要大量的測試機來支撐，而avalanche和siege體現出天生的資源佔用低、高效能的優勢，由於業務介面互動簡單也不存在功能不滿足的情況，所以該場景首選avalanche或siege來進行。

使用avalanche可以在單個千兆介面上實現18萬qps的能力，對於150萬qps的壓力需求可以繫結9個口進行。

對於沒有avalanche測試資源的情況，可以使用低成本的siege工具，siege可以在單臺雙路E5 cpu的測試機中實現18萬qps的壓力，並可以統計伺服器響應的http return code數量，對於150萬qps的壓力需求可以使用9臺伺服器做測試叢集，對比tsung，tsung大概需要25臺測試機來實現，對比loadrunner，loadrunner大概需要70臺測試機。

這裡需要注意的是，siege工具不支援分散式呼叫，在該場景下需要做一個簡單包裝來支援分散式，比如可以用python pexpect或shell rsh方式編寫指令碼來跨機操作多臺機器上的siege程序。

【場景4】

NSS Labs安全產品認證的測試方案中，許多安全產品的Performance測試都包含一項”Real-world”的混合流量測試，我們以NGFW這個產品的測試方案為例介紹一下如何選擇合適的工具實現，如下圖說明：

【選型分析】先看Enterprise的流量細節：

再分析各壓力工具實現Enterprise的混合流量，具體如下：

• 商用儀表Avalanche：支援Client/Server模擬多協議互動，混合流量比例可控、報表詳細（推薦）

• Siege：不適用上述的混合流量的多協議（不支援）

• Loadrunner/Jmeter/Tsung/Locust：需要單獨搭建各種協議的server，配置成本高，工具中需要配置多種協議測試指令碼，混合流量比例較難控制（困難）

跟據上述結論，我們看一下使用Avalanche如何實現Enterprise的混合流量：

第一步測試拓撲(Avalanche直連Firewall)：

第二步client&server配置具體引用層協議細節，以http_text為例：

①client端，配置http協議action為get

②server端，配置上傳112k大小文字檔案

③完成所有協議配置後，在Associations引用配置

完成上述配置完後，即可傳送流量驗證，結果如下

從上圖可以看出，獨立的協議顯示結果，過Firewall後可以獨立分析。關於NSS Labs的介紹，詳見360百科連結：

【場景5】

業務介面為java JMS/RMI型別，業務互動邏輯複雜，預期為100併發使用者，3000tps。

【選型分析】Java JMS/RMI為java私有的類RPC介面，測試時需要壓測工具載入對應的java類庫用於關聯各介面業務class method，目前只有loadrunner和jmeter支援java，loadrunner通過載入一個jvm來實現java支援，而jmeter為原生java實現。所以，對於java介面測試，只能選擇loadrunner/jmeter工具。

綜上所述，壓測專案的工具選型的考慮因素有：

• 被測端的業務邏輯

• 預期的壓力大小

• 工具二次開發能力

• 測試人員對工具語言的熟練度
   

而具體到上述六款工具總結如下：

• Avalanche：適合閘道器型別產品測試(同時模擬協議的C/S兩端進行互動)，壓力規模要求較高， 需要定製2-7層協議互動細節，多協議測試，測試報告有較高要求的場景，不適合業務互動複雜的場景；

• Siege：適合http/https型別的介面極限基準測試，較低成本實現大壓力規模要求的場景，不適合業務互動複雜及非http/https協議測試場景；

• Loadrunner：適合大多數測試場景，相關文件及社群資料豐富；

• Jmeter：適合大多數測試場景，尤其適合java私有介面測試(RMI/JMS)；

• Tsung：適合較低成本實現大壓力規模要求的場景，不適合業務互動複雜及需要工具功能擴充套件的場景；

• Locust：適合大多數測試場景，尤其適合需要工具功能擴充套件的場景；不適合較低成本實現大壓力規模要求的場景；

正所謂工具善其事，必先利其器，選用適當的工具，可以讓我們的工作事半功倍，期望這篇文章能夠給您的壓力測試工作帶來一些幫助，也非常歡迎您的意見和建議，大家一起交流效能測試領域的各種問題。