性能測試準備過程總結

準備階段

必要性分析

分析是否有必要進行性能測試；

被測對象分析

確認被測對象，並根據被測對象性質確認測試方案；

測試技術準備

根據被測對象準備測試技術不一樣協議測試工具、測試重點及方案是有區別的，例如http接口、rpc、websocket、udp測試技術不一樣，應根據不一樣的測試對象準備不一樣的測試方案

目標評估

評估被測服務性能指標預期結果

峯值QPS

已上線的需求能夠按目前線上狀態評估，這樣最準未上線的需求一種方式能夠找相似其它功能，沒有類似功能的話能夠找相似其它產品沒法參照的話可按全量工具評估總請求，平均到秒後再按「帕累托法則（八二法則）」乘以對應係數估算

• QPS

大部分單一接口的QPS=HPS，一條請求就是一次query，有少部分需求可能一次Hit有屢次Query，需瞭解具體業務實現

• TPS

複雜業務評估指標可以使用TPS（每秒處理事務數），常見的狀況像一次轉帳業務可能包含查詢、轉帳、覈對等幾個連續動做，這種連續動做可稱爲一次T，TPS常常用來評估邏輯處理的能力和用時；

響應時間

不一樣產品對響應時間的要求是不相同的，內存處理通常請求的響應時間應該在10ms之內，有數據庫讀寫的狀況可能稍長（redis通常是十毫秒級別，mongo稍長，mysql最長，但通常大小的數據也應該在百毫秒級別）超過百毫秒的狀況須要確認具體需求，及這類狀況佔比，響應時間指標通常有下面幾種級別；

• 平均響應時間

總時間/總請求數

• TP50

全部請求中處理最快的前50%請求中的最長耗時

• TP90

全部請求中處理最快的前90%請求中的最長耗時

• TP95

全部請求中處理最快的前95%請求中的最長耗時

• TP99

全部請求中處理最快的前99%請求中的最長耗時

• TP999

全部請求中處理最快的前99.9%請求中的最長耗時

• 錯誤響應數佔比

全部請求中非200返回碼的請求數佔比

• 超時率

全部請求中超時的請求數佔比需在壓測工具中定義一個超時時間

被測服務資源佔用指標預期

• 服務器cpu預期

程序有大量運算的狀況下cpu可能成爲瓶頸，例如dsa加密、大量檢索運算；

• 服務器內存預期

一、程序啓動時須要load大量數據到內存；二、程序運行時須要使用大量內存以增長處理速度（空間換時間）的狀況；

• 存儲預期

絕大多數的web服務存儲開銷都在log等功能需求上，且通常狀況log文件會定時傳走&清理，這裏要注意清理過程是否會存在log積壓；

• 帶寬預期

通常過大的靜態資源應放在專用的資源服務器上，帶寬問題常見於大量數據資訊返回或流媒體服務中；

• 端口數預期

端口問題常見於長鏈接服務，和須要做爲client端向子服務請求的需求；常見問題：一、time_wait過多；二、服務阻塞致使端口沒法釋放；

• 磁盤io預期

磁盤io問題常見於寫log的功能，業務邏輯中須要作磁盤io的需求已經很少了，由於數據在程序啓動時會被加載到內存中以提高讀寫速度；

相關依賴預期評估

• 依賴後端子服務

處理一個請求時須要向一個或多個後端服務請求資源；

• 依賴後端DB

處理一個請求時須要作db讀寫操做；

• 依賴運行環境，例如K8S集羣等

服務運行的環境可能致使性能不知足預期，例如當服務部署在虛機時，須要評估虛機處理能力；若是部署在k8s集羣時，需評估宿主機和集羣前端proxy處理能力；如請求流包含多個環節時，每一個環節都有壓力存在；

• 依賴外部資源，例如CDN服務等

場景：業務邏輯回返回cdn地址，客戶端收到地址後直接去cdn獲取數據；這類場景須要對cdn服務的處理能力和帶寬預期作評估；

• 依賴磁盤空間，例如log存儲

評估服務日誌量大小；

• 其它意想不到的依賴

場景：百度春晚紅包需求，百度紅包服務端性能符合預期，但整理邏輯中忽略了用戶習慣（用戶對百度的認知是搜索引擎而不是app，因此app的紅包功能對百度網頁搜索帶來了很是大的併發流量）致使搜索引擎主站癱瘓；百度紅包功能還對第三方app市場和appstore帶來大量流量，致使其服務癱瘓；

測試方案

測試方案應包含如下內容

被測對象（即性能測試需求中的功能-子功能）

測試目標

有預期的狀況：經評估的各個指標預期預期不明確的狀況：說明狀況，例如「此功能沒法預估預期qps狀態，上線後根據實際狀況調整」

測試環境

說明測試所用機器各項配置；

依賴說明

說明被測服務依賴的服務及功能的狀態或mock狀態

實驗分組及排期

每組的驗證點及環境、時間安排；

測試工具

http接口工具

• loadrunner

• locust

• jmeter

• wrk

grpc工具

• ghz

流量複製放大回放

• goreplay

websocket長鏈接

• websocket-bench

其它自定義協議等

• 本身編寫壓測腳本

可以使用go語言或python gevent庫等方案模擬大併發

測試用例

測試用例要覆蓋全部邏輯，能夠經過統計壓測用例覆蓋率的方法來肯定是否有遺漏邏輯；需評估未覆蓋的代碼邏輯是否須要補充用例；

測試環境

測試環境要儘可能與線上保持一致；不能保持一致的可選擇性能比線上少低一點的機器；若是服務是第一次上線，建議在不影響線上其它服務的狀況下（外圍有線上proxy，或須要讀寫線上數據庫等相似狀況不能直接使用測試環境進行性能測試）直接只用線上環境進行性能測試；

子服務&測試配置準備

測試中臺服務時須要準備與生產環境一致的子服務或微服務，沒有條件準備時可以使用mock服務替代；

風險預案

對重要的被測系統應該作planB，例如：一組服務爲節省資源，使用8臺服務器，評估可知足需求；但可能存在短時大併發的狀況，因此，在上線之初或有運營活動以前，應準備一些備用機，當線上監控報出問題時，馬上擴容；