基於雲的全鏈路性能測試理念與產品實踐

2016年京東618電商節已經告一段落，從6月1日到18日的大促期間，京東累計訂單量過億，618當天（00:00-24:00）下單量同比增加超過60%。其中，移動端下單量佔比達到85%，是去年同期的2.2倍。如何保障大流量下的系統高可用性，成爲京東電商平臺每一年一度的「高考」。

因爲京東平臺架構的複雜性，爲了保證系統的高可用，在傳統壓力的基礎上，京東全面採用了線上壓測和全流程壓測，以觀察多系統在峯值流量下的相互影響，而這些測試手段均可以概括爲性能測試。性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。經過負載測試，肯定在各類工做負載下系統的性能，發現系統負載增長時，各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接受的性能點，來得到系統能提供的最大服務級別的測試。
爲何要進行性能測試呢？
本文開始提到了京東618的例子，設想一下，若是在618當天由於暴增的流量致使系統崩潰，京東的網站、APP沒法打開，支付不能正常交易，會給京東帶來多少損失？

國外調研機構針對網站性能作過調查顯示：響應時間每延遲一秒，客戶轉化減小7%，頁面訪問量減小11%，客戶滿意度下降16%。性能除了會形成收入的損失，還會嚴重損害企業的品牌，而1個互聯網用戶會用負面口碑影響17個其餘用戶。
全球電商巨頭亞馬遜每100ms的訪問延遲會形成1%的銷售損失，而1秒鐘的訪問延遲給亞馬遜帶來每一年16億美圓的鉅額損失。在中國，2015年5月28日攜程旅行網出現長達7個小時的服務癱瘓，官網和App均沒法訪問，形成的直接損失約5000萬元人民幣。性能測試對業務的重要性一目瞭然。
常見性能測試術語介紹
要作好性能測試，首先要熟知性能測試的如下概念：
VU 虛擬用戶數：這個概念相信你們都不陌生，線上環境裏的每個操做都是一個真實用戶的操做，而在測試環境不可能找來那麼多的測試用戶，就要用程序模擬真實用戶去跑，這就是虛擬用戶~~
VUM 每分鐘虛擬用戶數：這是一個負載參數，通常也會用來跟計費掛鉤。阿里雲的PTS就是按照VUM來收費的。也有壓測產品Web Load Testing是按照VUH來計費的，這裏的H是小時的概念。
下面介紹一下雲智慧壓測寶兩種曲線模式裏計算VUM的不一樣算法。

平行模式：如上圖所示，在一段時間內虛擬用戶數保持不變，VUM＝VU*M

坡度模式：顧名思義，坡度模式下虛擬用戶數隨着時間的變化而增長或減小。坡度模式的計算方法比較複雜，與選擇曲線模式的順序和類型，即整個壓力曲線的變化方式有關，最簡單的狀況下VUM＝（VU*M）／2 。
TPS （Transaction Per Second）每秒鐘事務數：每秒鐘系統可以處理事務或交易的數量，它是衡量系統處理能力的重要指標。
QPS（Queries Per Second）每秒鐘請求數：若是一個腳本共3個請求，跑完一遍算一個事務數。假如1秒鐘，就跑了一遍這個腳本，那麼TPS=1，QPS=3。
併發用戶數：多用戶在同一時刻對系統執行操做，通常指執行同一事務或操做。例如你們輸入完用戶名和密碼後，同時點擊登陸按鈕，這個登陸就是一個併發操做。若是100我的同一時刻點擊登陸，那麼咱們認爲此時併發數爲100。
在實際性能測試工做中，測試人員通常比較關心的是業務併發用戶數，也就是從業務的角度關注應該設置多少個併發數比較合理。以一個典型的上班簽到系統爲例，早上8點上班，7點半到8點的30分鐘的時間裏用戶會登陸簽到系統進行簽到。公司員工爲1000人，平均每一個員上登陸簽到系統的時長爲5分鐘，用下面的公式計算：
　　　　C=1000/30*5=166.7
C表示平均併發用戶數，那麼對這個簽到系統每分鐘的平均在線用戶數爲166
固然，在性能測試上，任何公式都不能徹底模擬真實狀況的發生，最重要的是對系統作出有效正確的分析。
吞吐量：單位時間內系統處理的客戶請求數量。通常用請求數/秒或者頁面數/秒來衡量。
響應時間：應用系統從客戶端請求發出開始到客戶端接收到最後一個字節數據所消耗的時間。

6
響應時間=N1+A1+N2+A2+N3+A3+N4
針對響應時間，業內有「2-5-8原則」的說法，就是當用戶可以在2秒之內獲得響應時，會感受系統的響應很快；當用戶在2-5秒之間獲得響應時，會感受系統的響應速度還能夠；當用戶在5-8秒之內獲得響應時，會感受系統的響應速度很慢，可是還能夠接受；而當用戶在超過8秒後仍然沒法獲得響應時會感受系統糟透了，或者認爲系統已經失去響應，而選擇離開這個Web網站，或者發起第二次請求。
對於API請求，因爲沒有頁面的渲染時間，因此響應時間會更快，纔會不影響用戶的體驗感知。
思考時間（Think Time）：用戶在進行操做時，每一個請求之間的間隔時間。一般在輸入用戶名、登陸密碼或選擇查詢條件等等的操做中是須要有停頓時間去輸入或選擇的。因此爲了更真實的接近真實場景，須要加入一些思考時間。
資源使用率：負載下的基礎設施資源使用狀況，一般包括CPU佔用率（用戶使用率（%User），系統（%System））， 內存使用率，磁盤I/O， 網絡I/O（帶寬的流入和流出），這些參數經過雲智慧透視寶能夠實時得到監控性能指標。
常見性能測試工具
目前市面是比較流行的性能測試工具主要有如下幾種：

1. Load Runner：Load Runner是目前的業內老大，功能比較強大，商品版本須要購買Licence，進行性能測試時能夠看到實時和已經完成的報告。不過產品配置比較複雜，新手入門須要花較長時間。

2. 阿里雲的PTS（Performance Test Service）：阿里雲PTS產品完成度不高，新手幫助不少打不開，驗證腳本比較麻煩，在試用時測試任務創建後都失敗了。

3. 雲智慧壓測寶：壓測寶是基於SAAS的性能測試產品，全鏈路的壓測，簡單易用，上手很快。

4. Soasta的CloudTest：CloudTest功能很是強大，報告自定義面板很贊！可是國外的產品，雖然支持中文，但兼容很差。

5. Jmeter：上手很簡單，大量併發時會有內存溢出問題，Jmeter的報表較少，對於要分析測試性能不足做爲依據，不過做爲簡單的接口測試和少許併發仍是不錯的。
   壓測寶功能實戰

傳統的壓力測試一般被稱爲溫室環境的壓力測試。而壓測寶基於雲端的全鏈路壓力測試則是真實環境壓力測試。經過下表能夠對比一下傳統壓測和雲壓測的區別。

壓測寶的優點有：
面向真實用戶業務場景及真實地域分佈的性能測試；
基於壓測分析應用全鏈路性能瓶頸；
集成透視寶應用性能管理深刻代碼級問題定位；
集成透視寶分析後端的主機性能指標；
自定義多維度數據實時分析報表
除了自身的功能優點，壓測寶還能和雲智慧另外兩款產品——監控寶和透視寶的深度集成，達到1+1+1>3的效果：在上線以前由壓測寶發起壓力，透視寶定位具體的瓶頸[主機，服務，代碼等] ，在上線以後與監控寶集成，利用一樣的腳本進行線上業務的監控告警。
壓測寶的壓測步驟很是簡單，能夠分三步走：

1.準備測試腳本和測試數據
測試腳本支持6種http請求（post，get，delete，put，option，head），支持http和https協議。在準備腳本的時候，應該驗證腳本是否正確可用的，而後建立測試任務，否則就可能白白浪費測試資源啦~~

壓測寶的腳本驗證很是簡單，一步到位就能夠看到結果，而阿里雲的PTS須要3步。

若是測試任務須要使用測試數據的話，要在測試腳本中定義這些初始化變量。測試數據支持csv和zip的導入，單個文件大小在60M之內。

2.定義測試任務：
一個測試任務能夠跑不一樣的腳本，測試腳本能夠綁定測試數據，也能夠不綁定測試數據。用戶可以本身設定腳本的比例。

壓力曲線設置：壓測寶支持多個壓力曲線的設置，建議先使用坡度模式，找到性能拐點後再設置平行模式。固然若是公司的性能要求必須保證500併發，也能夠直接選擇500VU 平行，看系統是否支持500VU。

壓測點設置：壓測寶用戶能夠根據企業實際用戶分佈選擇最適合本身的壓測點。

3.實時數據分析
運行中的壓測報告是每隔10s刷新一次，能夠實時查看TPS，方便客戶的開發或者運維人員第一時間發現和定位性能瓶頸。若是出現嚴重的錯誤，如整個客戶系統癱瘓，能夠馬上終止當前測試任務，節省VUM。
概要分析：

地域分析

事務分析

已經完成的任務一樣會輸出詳細的數據報告，用戶能夠根據時間，腳本，地域等對結果進行過濾。另外壓測寶還會有幫助手冊，幫助視頻等幫助新手入門。