本文作者：
殷成濤（花名：風起），阿裡雲PTS開發工程師，專注于性能壓測與高可用架構領域
本文緻力于給出性能壓測的概念與背景介紹，同時針對市場上的一些性能壓測工具，給出相應的對比，進而幫助大家更好地針對自身需求實作性能壓測。
為什麼要做性能壓測
在介紹性能壓測概念與背景之前，首先解釋下為什麼要做性能壓測。從09年的淘寶雙十一大促導緻多家合作銀行背景系統接連當機，到春運期間12306購票難，再到前不久聚美優品促銷活動剛開始就遭秒殺。根據Amazon統計，每慢100毫秒，交易額下降1%。這些事件和統計資料為大家敲響了警鐘，也客觀說明了性能壓測對于企業應用的重要性。
從具體的作用上講，性能壓測可以用于新系統上線支援、技術更新驗證、業務峰值穩定性保障、站點容量規劃以及性能瓶頸探測。
1. 新系統上線支援
在新系統上線前，通過執行性能壓測能夠對系統的負載能力有較為清晰的認知，進而結合預估的潛在使用者數量保障系統上線後的使用者體驗。
2. 技術更新驗證
在系統重構過程中，通過性能壓測驗證對比，可以有效驗證新技術的高效性，指導系統重構。
3. 業務峰值穩定性保障
在業務峰值到來前，通過充分的性能壓測，確定大促活動等峰值業務穩定性，保障峰值業務不受損。
4. 站點容量規劃
通過性能壓測實作對站點精細化的容量規劃，指導分布式系統機器資源配置設定。
5. 性能瓶頸探測
通過性能壓測探測系統中的性能瓶頸點，進行針對性優化，進而提升系統性能。
綜上所述，性能壓測伴随着系統開發、重構、上線到優化的生命周期，是以有效的性能壓測對系統的穩定性具有重要的指導意義，是系統生命周期中不可或缺的一部分。
性能壓測概念
性能壓測是通過自動化的測試工具模拟多種正常、峰值以及異常負載條件來對系統的各項性能名額進行測試。
從測試目的上性能壓測又可以劃分為負載測試、壓力測試、并發測試、配置測試以及可靠性測試。
- 負載測試是測試當負載逐漸增加時，系統各項性能名額的變化情況。
- 壓力測試是通過确定一個系統的瓶頸或者不能接受的性能點，來獲得系統能提供的最大服務級别的測試。
- 并發測試通過模拟使用者并發通路，測試多使用者并發通路同一個軟體、同一個子產品或者資料記錄時是否存在死鎖等性能問題。
- 配置測試是通過對被測系統的軟/硬體環境的調整，了解各種不同方法對軟體系統的性能影響的程度，進而找到系統各項資源的最優配置設定原則。
- 可靠性測試是在給系統加載一定業務壓力的情況下，使系統運作一段時間，以此檢測系統是否穩定。
總的來說，性能壓測是在對系統性能有一定程度了解的前提下，在确定的環境下針對壓測需求進行的一種測試。
如何選取性能壓測工具
在選取合适的性能壓測工具之前，我們需要先先了解執行一次完整的性能壓測所需要的步驟：
1. 确定性能壓測目标：性能壓測目标可能源于項目計劃、業務方需求等
2. 确定性能壓測環境：為了盡可能發揮性能壓測作用，性能壓測環境應當盡可能同線上環境一緻
3. 确定性能壓測通過标準：針對性能壓測目标以及選取的性能壓測環境，制定性能壓測通過标準，對于不同于線上環境的性能壓測環境，通過标準也應當适度放寬
4. 設計性能壓測：編排壓測鍊路，構造性能壓測資料，盡可能模拟真實的請求鍊路以及請求負載
5. 執行性能壓測：借助性能壓測工具，按照設計執行性能壓測
6. 分析性能壓測結果報告：分析解讀性能壓測結果報告，判定性能壓測是否達到預期目标，若不滿足，要基于性能壓測結果報告分析原因
由上述步驟可知，一次成功的性能壓測涉及到多個環節，從場景設計到施壓再到分析，缺一不可。工欲善其事，必先利其器，而一款合适的性能工具意味着我們能夠在盡可能短的時間内完成一次合理的性能壓測，達到事半功倍的效果。
工具選型對比
在論述了性能壓測必要性之後，如何選取性能壓測工具成為一個重要的議題？本文選取了市場上主流性能壓測工具：（ab）Apache Bench、LoadRunner、JMeter、阿裡雲PTS，并從多個方面出發分析了各個工具的優缺點，彙總後的優缺點如下表所示：
Apache Bench（ab）
ab是一款用來針對HTTP協定做性能壓測的指令行工具，支援在本地環境發起測試請求，驗證伺服器的處理性能。它主要具有以下特點：
首先，作為一款開源工具，ab具有較好的擴充性，測試開發人員可以基于自身需求對其進行二次開發，同時它對HTTP協定支援度較好，比如支援設定HTTP請求頭、支援Cookie以及HTTP的多種方法。
此外，使用ab時還可以通過指定性能壓測産生的總請求數、并發數與壓測時長控制性能壓測，結合其能夠輸出性能壓測過程中的TPS（每秒事務數）、RT（響應時延）等資訊的特點，ab具有簡單易上手的特點。
但ab也存在一些缺點，如無圖形化界面支援，支援協定較為單一，隻支援HTTP協定，缺少對HTTPS協定、WebSocket等協定的支援，對于較為複雜的性能壓測場景，ab缺少鍊路編排、場景管理等支援，隻能夠對單一位址發起性能壓測，此外，它的性能壓測統計名額緯度較少，缺少性能壓測過程中的資料統計，隻能夠在壓測結束後擷取相關的統計資料，無法實時擷取系統負載等名額，難以應用于生産環境下的性能壓測。
總的來說，ab作為一款指令行測試工具，适用于本地對支援HTTP協定的單一位址進行性能壓測，但缺少相應的鍊路編排、場景管理、資料可視化等大規模性能壓測基礎功能，無法應用于生産環境。
LoadRunner
LoadRunner，是一款釋出于1993年11月的預測系統行為和性能的負載測試工具。通過以模拟上千萬使用者實施并發負載及實時性能監測的方式來确認和查找問題，LoadRunner作為一款曆史悠久的商業性能壓測工具，能夠對整個企業架構進行測試。企業使用LoadRunner能最大限度地縮短測試時間，優化性能和加速應用系統的釋出周期。 LoadRunner可适用于各種體系架構的自動負載測試，能預測系統行為并評估系統性能。
LoadRunner從元件上可劃分為四部分：
- 負載生成器：模拟使用者對伺服器發起請求
- 虛拟使用者生成器：捕捉使用者業務流，用于錄制和生成腳本
- 控制器：用于提供場景設計與場景監控，能夠實時監控腳本的運作情況
- 分析器：彙集來自各種負載生成器的日志并格式化報告，以便可視化運作結果資料和監控資料
從元件劃分上可以看出 LoadRunner 對于性能壓測擁有較為系統的支援，結合多個元件的功能特性，使用者可以較為友善地設計複雜背景下的性能壓測場景，例如結合場景設計設定虛拟使用者數量、設定執行時間等，結合虛拟使用者生成器實作複雜鍊路、場景的高效設計與編排。
此外，LoadRunner支援設定思考時間、集合點，還可以結合分析器實作壓測報告統計資料、名額的可視化，助力測試人員了解性能壓測結果。
但 LoadRunner 作為一款商業軟體，價格較高，需要本地安裝，安裝過程較複雜，在實際設計執行壓測時需要編寫相應的腳本，對使用人員來說學習成本比較高，此外缺少監控告警等支援，性能壓測過程中難以實時發現問題。
總的來說，LoadRunner 作為一款性能壓測商業軟體，功能較為齊全，使用者能夠借助 LoadRunner 達到簡單的性能壓測場景編排、施壓目标；但它也存在學習成本居高不下、擴充性差等缺點，此外支援的協定有限，不适合複雜的性能壓測環境。
JMeter
Apache JMeter是Apache組織開發的基于Java的壓力測試工具。它可以用于測試靜态和動态資源，例如靜态檔案、Java 小服務程式、CGI 腳本、Java 對象、資料庫、FTP 伺服器等等。另外，JMeter能夠對應用程式做功能/回歸測試，通過建立帶有斷言的腳本來驗證你的程式傳回了你期望的結果。為了最大限度的靈活性，JMeter允許使用正規表達式建立斷言。同時JMeter支援對性能壓測結果做圖形分析。
JMeter 作為一款開源軟體，擴充性強，具有強大的開源社群支援，社群内開發者活躍程度高，也正是在開源社群的積極發展下，JMeter 具有性能壓測的諸多特性，如支援場景編排、斷言設定，支援對多種資源施壓，有圖形化界面支援，支援腳本錄制，使用人員能夠較為簡單的設計并發起性能壓測，此外 JMeter 提供資源監控、性能壓測報告生成等功能。
但在需要高負載施壓的場景下，JMeter 需要部署分布式環境，部署成本比較高，在使用時，需要編寫相應的腳本，而每個腳本檔案隻能儲存一個測試用例，學習門檻居高不下的同時也不利于腳本的維護，此外它缺少監控告警等支援，在性能壓測過程中使用人員難以借助 JMeter 實時發現問題。
作為一款時下熱門的開源性能壓測工具，根據谷歌搜尋指數顯示，JMeter 已經逐漸展現出了替代 LoadRunner 的趨勢，如圖：
同時活躍的社群環境、開發者生态也進一步促進了JMeter的功能完善，未來的發展值得期待。但于此同時，JMeter也存在學習、維護成本高，缺少監控告警等功能支援，難以應用于大型複雜的性能壓測場景。
PTS
性能測試服務（Performance Testing Service，簡稱 PTS）是一個 SaaS 性能測試平台，提供場景 API 編排功能。結合阿裡巴巴的自研平台和引擎，支援按需設定壓測模式、壓測量級、壓測時間，快速發起壓測，監控壓測過程并生成報告等功能，同時也相容開源工具 JMeter。
下面将從功能、性能、生态與監控四個方面展開介紹 PTS：
功能方面
PTS 提供了鍊路、場景編排壓測報告導出的功能、，除了傳統的并發模式（虛拟使用者并發），PTS也支援 RPS 模式（Requests per Second），也即吞吐量模式，RPS 模式為 PTS 獨有，具有能夠更精準地衡量服務端系統能力等優點。為了降低發起性能壓測的門檻，PTS 提供雲端錄制器，便于用戶端的請求抓取，同時還可将抓取的請求一鍵導入到壓測場景中；為了适配不同場景下的性能壓測，PTS 支援建立服務等級協定 SLA（Service Level Agreement）規則，能夠實作對業務壓測場景更智能的控制和更全面合理的評價，同時，PTS 也提供了大量 SLA 模闆供不同背景下的使用者使用；此外，PTS 還支援定時壓測，能夠指定啟動壓測的日期、時間以及循環周期等，能夠在任意時間段自由發起性能壓測，釋放人力。
性能方面
PTS 能夠随機排程遍布全國各地的壓測引擎，一分鐘内快速啟動性能壓測，模拟真實環境下的使用者請求；支援最高千萬級的流量瞬時脈沖，多重機制確定壓測流量及時停止；支援兩種調速模式：自動遞增和手動調整，壓測流量調整秒級生效。
生态方面
PTS 支援添加阿裡雲生态内的雲監控産品，如添加阿裡雲生态内的性能管理類産品ARMS，提供應用級别的監控，為性能壓測提供問題定位的閉環能力；此外 PTS 雲端內建 JMeter，使用者隻需在本地完成 JMeter 腳本調試，即可在 PTS 上快速發起壓測。
監控方面
PTS 監控名額包括每個 API 的并發，RPS (Requests per Second)、響應時間、采樣的日志等。同時從不同細分次元，統計了 API 請求的成功、失敗情況和響應時間，能夠幫助使用者快速定位到系統的性能瓶頸。此外，PTS還能夠結合阿裡雲生态内的雲産品監控，如監控ECS、SLB及RDS等在内的各産品性能名額；為雲上服務提供更為詳盡的監控。
總的來說，阿裡雲 PTS 作為一款雲服務，使用者可以較低的學習成本快速借助 PTS 發器壓測，對于阿裡雲的使用者來說，PTS 能夠緊密結合現有的阿裡雲服務，提供全方位的壓測報告供使用者快速定位性能瓶頸；對于 JMeter 使用者，也能夠以較低的成本遷移至 PTS，享受 PTS 的高階功能。但 PTS 也存在一些問題，擴充性需要加強，例如需要支援更多網絡協定。
實際案例
某創業公司A即将上線一項新功能，為了在上線前充分測試，保障服務的高可用性，測試人員給出了相應的測試需求：
- 為了盡可能避開業務高峰期，需要在每天的淩晨一點鐘測試；
- 測試時，認為業務的正常響應時間應當在 550 ms 以下，連續三次響應時間超出550 ms 時應當向負責人發出通知，連續三次響應時間超出800 ms 則應當停止壓測；
- 為了模拟真實的使用者流量，需要設定流量一半來源于移動營運商，一半來源于聯通營運商；
- 公司希望在對自身業務監控的同時，能夠監控到所使用阿裡雲上ECS、RDS等雲服務的資源使用狀态；
結合上述的各性能壓測工具優缺點，僅有 PTS 滿足客戶需求，下面我們具體看一下 PTS 如何實作該案例需求。
首先為了能夠實作每天淩晨一點測試，我們可以使用 PTS 所提供的定時壓測功能，通過把場景設定為定時壓測任務，結合cron表達式可以實作每天淩晨一點自動運作該壓測場景，配置如下圖所示：
接着為了實作連續三次響應時間超出550 ms 後，向負責人發送通知；連續三次響應時間超出800 ms 停止壓測，可以利用 PTS 所提供的 SLA 功能實作，配置如下圖所示：
在配置 SLA 規則後，還可以設定 SLA 規則應用鍊路，以及報警通知人，如下圖所示：
接下來為了能夠實作流量一半來源于移動營運商，一半來源于聯通營運商，我們可以利用 PTS 所提供的流量地域定制功能，指定壓測引擎營運商，如下圖所示：
最後，為了能夠在壓測過程中以及壓測報告中檢視到阿裡雲ECS、RDS等監控狀态，可以在添加監控中添加對應的監控項，如下圖所示：
綜上，PTS 的各項配置成功地滿足了該創業公司的壓測需求，在避免員工夜間值班壓測，節省了公司人力資源的同時，提升了該公司的性能壓測效率，在最終的壓測報告中，客戶可以觀察到業務的性能名額以及所使用雲服務的資源使用狀态，通過對壓測報告的解讀可以快速定位到服務的性能瓶頸，提升服務品質。
總結
本文介紹了性能壓測的概念以及相關背景，并針對目前幾款閱聽人相對較多的性能壓測工具給出了優缺點分析，每種工具都有相應的優缺點，大家可以針對自身需求選取合适的性能壓測工具。