壓測2.0：雲壓測 + APM = 端到端壓測解決方案

從壓力測試提及

壓力測試是確立系統穩定性的一種測試方法，一般在系統正常運做範圍以外進行，以考察其功能極限和隱患。與功能測試不一樣，壓測是以軟件響應速度爲測試目標的，尤爲是針對在較短期內大量併發用戶的訪問時，軟件的抗壓能力。

至於爲何產品或業務系統在經過功能測試後還須要進行壓力測試，緣由很簡單，由於它重要，爲何重要？衆所周知，響應速度是用戶體驗的核心指標之一。 SmartBear 數據代表，若是 Amazon 的加載時間延長1秒，那麼一年就會減小16億美圓的營收。用戶與網站互動的過程當中，若是加載時間超過3秒，57% 的用戶會流失。可見，經過壓測來優化產品體驗和性能是多麼的重要。

壓測1.0 VS 壓測2.0

傳統的壓測方法一般的作法須要準備大量的環境，如測試的壓力機，安裝測試工具，錄製測試腳本，對服務器不斷施加「壓力」，經過這種方式來肯定系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試，這個階段咱們稱之爲壓測1.0。

壓測1.0時代的主流壓測工具備 LoadRunner ， SilkPerformer ， Ratinal ， QA Load ， Jmeter 等等， LoadRunner 爲傳統壓測1.0時代最主要的表明產品。

圖1.傳統的壓測現狀

傳統的測試方法下很難去作到對整個系統去作一次大型的壓力測試，這種狀況下只能把每一個系統獨立開來，對他進行性能測試，而後對整個核心系統去作分析，肯定系統的短板，對短板進行壓力測試。

一般須要用預估的方式，業務部門估算今年的交易額，應用部門估算，網絡部門估算，基礎架構部門估算。最後的結果就是若是須要1000臺服務器，那麼就準備1500臺。若是須要5 G 的 CDN 帶寬，那麼就準備7.5 G 。幾乎全部資源都多準備50%。

壓測1.0時代的壓測缺點很明顯。

• 測試過程緩慢，週期過長

• 並不是聚焦於全球客戶的體驗

• 很是昂貴的受權費用及硬件投入

• 爲實驗室測試而設計，對生產或線上環境無能爲力

• 不能針對當今複雜的應用及架構提供實時的反饋

基於雲計算的全鏈路壓力測試咱們稱之爲雲壓測，這個階段咱們叫壓測2.0。雲壓測經過遍及雲端的壓力模擬服務器，來製造「真實用戶訪問」，這個過程能夠覆蓋到真實交易系統的全鏈路，全業務測試系統，而且革命性的使用雲資源這種輕屬性資產，對幾乎來自全世界互聯網和移動互聯網的壓力進行測試。雲壓測模擬測試徹底還原真實用戶網絡訪問情況。

圖2.「雲壓測+ APM 」進入壓測2.0時代

__當產生壓測需求時，咱們佈置在各主流雲廠商（AWS、阿里雲、Azure、青雲、騰訊雲、金山雲、UCloud等等）的壓測虛機自動下發壓測腳本，進行雲端託管式部署__雲端壓測機啓動，對用戶系統進行壓測。同步壓測，同步產出壓測數據。

利用雲計算優點，當須要進行模擬大規模用戶訪問時，只要多開雲主機就能實現，須要模擬100萬的用戶訪問，再開100臺雲主機。

雲壓測的準備時間基本上就是由雲主機啓動時間來決定，這在壓測1.0時代是根本不可能實現的。雲壓測是在雲主機發起的，所以反映了真實的用戶訪問環境，而壓測1.0時代的傳統壓測方式則必須在內網的模擬環境下進行。

壓測2.0時代有點一樣明顯。

• 迅速部署

• 實時統計

• 真實世界的規模和模擬

• 分佈式的用戶

• 高效且持續

• 除去了硬件投入

壓測1.0時代的 LoadRunner VS 雲壓測

雲壓測 + APM = 端到端的性能優化解決方案

圖5.雲壓測 + APM 典型應用場景

與壓測1.0時代只關注於後端性能不一樣，雲壓測關注前端和後端性能，從前端的不一樣物理位置、不一樣運營商鏈路、寬帶、窄帶、帶寬、 CDN 、防火牆、負載均衡，到後端的應用軟件、數據庫、硬件資源、系統配比等，雲壓測在測試環境中還原真實業務環境。

雲壓測和 APM 結合，全鏈路全業務接口壓力測試，全面覆蓋先後端全部環節真正實現端到端性能優化解決方案，全方位提高用戶體驗。

OneAPM 爲更多企業提供全棧式的性能管理以及 IT 運維管理服務。閱讀更多文章，請訪問 OneAPM 官方技術博客

點擊此處，免費申請 OneAPM 雲壓測產品試用