效能測試的指標和工具
一.測試說明
測試的目的在於知道機器最大可以抗壓多少流量，並找出薄弱環節進行優化。
在測試後要進行容量規劃，目的在於讓每一個業務系統能夠清晰地知道：什麼時候應該加機器、什麼時候應該減機器。當節日時候業務增長，準確的預估將節省很多資金，並讓業務不會被流量擊倒。
容量規劃分為幾個階段：
- 業務流量預估階段：通過歷史資料分析未來某一個時間點業務的訪問量會有多大；
- 系統容量評估階段：初步計算每一個系統需要分配多少機器；
- 容量的精調階段：通過全鏈路壓測來模擬大促時刻的使用者行為，在驗證站點能力的同時對整個站點的容量水位進行精細調整；
- 流量控制階段：對系統配置限流閾值等系統保護措施，防止實際的業務流量超過預估業務流量的情況下，系統無法提供正常服務。
二.測試分類
單鏈路：
對單臺機器進行測試，通過ab等測試工具進行單臺機器的不同頁面併發量測試。觀察web伺服器的壓力和負載情況
如何測試單臺機器：
-
模擬請求：通過對生產環境的一臺機器發起模擬請求呼叫來達到壓力測試的目的，模擬請求和真實業務請求之間存在的差異，會對壓力測試的結構造成影響。同時模擬進行購買等操作，會對資料庫造成汙染，畢竟是虛假資料。
-
複製請求：通過將一臺機器的請求複製多份傳送到指定的壓測機器，這樣準確性更高，但同樣面臨資料汙染的問題。
-
請求轉發：將分散式環境中多臺機器的請求轉發到一臺機器上，也可以調節負載均衡的權重，讓測試機器承擔更多壓力，這樣因為都是正常請求不會對資料庫進行汙染。
全鏈路：
基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，比如購物平臺是nginx反向代理，後端為java程式，在測試中，模擬使用者登入賬號，選購商品，加入購物車，付費。這樣對整個鏈路進行測試，在觀察中，要對每個環節都進行觀察，找出薄弱和反應慢的節點。
為何要進行全鏈路測試？因為單臺測試再好，在一個業務的鏈路上，有一個下游系統出現了問題，響應時間變得很長。這個問題在鏈路上會被放大，甚至導致整個鏈路不可用。所以也要進行流控，當一個應用響應的時間超過閾值，我們可以認為這個應用不可控，應該迅速將它降級。
如何測試全鏈路：
全完模擬使用者對網站或者app發起請求，登陸--選購--購買。對於模擬請求的方式，需要考慮髒資料的處理方式。全鏈路壓測的所有資料都在生產環境做了資料隔離，包含儲存、快取、訊息、日誌等一系列的狀態資料。在壓測請求上會打上特殊的標記，這個標記會隨著請求的依賴呼叫一直傳遞下去，任何需要對外寫資料的地方都會根據這個標記的判斷寫到隔離的區域。
三.壓力測試指標
- TPS：每秒鐘完成的web請求響應數量
- 併發數：時間段內，系統同時處理的web請求響應數量
- 響應時間：所有web請求處理完畢的時間
- 頁面狀態：返回狀態碼是否都是正常200
- 資料傳輸量：每秒從伺服器獲取多少資料
四.壓力測試技巧
- 壓力測試工作應該放到產品上線之前，而不是上線以後；
- 測試時併發應當由小逐漸加大，比如併發100時觀察一下網站負載是多少、開啟頁面是否流暢，併發200時又是多少、網站開啟緩慢時併發是多少、網站打不開時併發又是多少；
- 更詳細的進行某個頁面測試，如電商網站可以著重測試購物車、推廣頁面等，因為這些頁面佔整個網站訪問量比重較大。
- 確定下web應用的協議，如果只是web伺服器的話一般用http或者https協議，如果有APP客戶端的話還要確定下其採用的協議。
- 採用壓測工具啟動機器人對伺服器進行施壓，觀察一些重點指標（TPS，響應時間，頻寬流量，CPU，記憶體，DB）等。
- 如果硬體效能都還OK的話，可以逐步增加壓力。如果測試過程中發下某個或者多個指標飆升（CPU達到90%以上，記憶體佔用很高等），可能觸及瓶頸了。
- 對於一些IO較大的請求也要觀察下頻寬的佔用情況（可能邏輯伺服器毫無壓力，但是頻寬已經早就滿了）。對於壓測過程也需要時刻關注db的效能，慢查詢是否變多。
- 在測試後需要對整體進行分析，檢視哪個頁面或者業務訪問量最大，還有資料庫負載慢查詢等等。