如何做好壓測

摘要： 事前準備 要做好一個壓測，首先要了解下面的一些背景知識，才能做好壓測計劃。 瞭解你的壓測目標：有多少流量？大概的分佈是怎樣的？需要壓測的 QPS 是多少？ 瞭解業務系統：各個業務場景對應的介面是什麼？介面背後有些什麼依賴（資料庫、快取、OSS）？ ...

事前準備

要做好一個壓測，首先要了解下面的一些背景知識，才能做好壓測計劃。

1. 瞭解你的壓測目標：有多少流量？大概的分佈是怎樣的？需要壓測的 QPS 是多少？

1. 瞭解業務系統：各個業務場景對應的介面是什麼？介面背後有些什麼依賴（資料庫、快取、OSS）？

1. 壓測資料準備：是否需要準備不同的請求資料？寫操作如何處理髒資料？讀操作注意響應大小對效能的影響？

1. 後端依賴摸底：是否需要 mock 掉一部分後端依賴？mock 對評估的準確性有多大影響？

例如根據業務評估和系統場景的細分，最終確定了壓測的目標：

按照 10w DAU 使用者量預估，PV = 15 * DAU = 1500000，平均分佈在 8 小時內，總 QPS = 52。

壓測效能標準

為了保證壓測得到的資料下，使用者體驗不受影響，要保證壓測過程中滿足下列的效能條件，否則壓測得到的資料可能是虛高的。

指標	要求	備註
CPU	<= 70%
響應時間	<= 100ms	特殊介面特殊分析
峰值錯誤率	<= 1%	儘量做到無錯誤
load1 值	< CPU 核數 - 0.5	例如 4 核 ECS，則 load1 最大為3.5
記憶體	<= 80%	儘量不能隨壓力變大而增加記憶體消耗

壓測環境和工具

可以編寫 lua 指令碼來定製請求的引數，例如我們可以通過下面的指令碼來實現同時按照不同的比例對不同的介面進行混合壓測

壓測過程中我們要觀察什麼？

系統指標

根據效能壓測標準中指定的需要觀察的內容，需要監控系統的一系列指標，包括 CPU，load，記憶體，響應時間等等，我們可以通過下面的手段來檢視這些指標：

• 壓測平臺：如果是內部系統壓測，使用壓測平臺可以檢視到實時的 QPS、響應事件等資訊

• xflush：檢視叢集或者單機的 CPU / 記憶體 / Load 等效能指標，PV / 資料庫訪問量 / 遠端服務呼叫量等業務指標

• tsar：在每臺機器上執行 tsar 可以檢視到實時的 CPU / Load / Traffic 等指標

• 日誌：通過日誌可以找到一些慢請求或者實現一些特殊場景的監控

在觀測過程中，還需要注意機器的負載是否均衡，每一臺機器上各個 CPU 是否負載均衡。可以觀測各個程序的 CPU 或者通過日誌來判斷。

CPU Profile

為了發現真實場景下的效能瓶頸，建議在壓測的過程中使用 alinode 生成一份 CPU Profile，從中尋找效能瓶頸進行優化，建議挑選達到最高 QPS 時，在長時間的穩壓過程中來生成 CPU Profile。

一般來說，現在 node 使用的 v8 版本已經對各種 js 的寫法都已經優化的很不錯了，很難通過改變 js 層面的寫法提升效能，最有效的優化手段是下面這幾種：

1. 通過空間換時間，如果可以的話，通過增加快取的方式來避免熱點程式碼的多次執行。

1. 優化熱點程式碼的演算法複雜度。

1. 優化業務邏輯，避免執行熱點程式碼。

其他依賴

根據“事前準備”中我們瞭解到的業務技術架構，需要進一步觀察對應的其他依賴服務和系統的指標：

1. 如果請求資料庫，觀察資料庫的 CPU / 記憶體佔用，是否有慢查詢？

1. 如果請求快取，觀察快取的命中率，準備的測試資料是否足夠分散和真實環境的命中率相差不大？CPU 和記憶體佔用率如何？

1. 如果請求後端系統，觀察後端系統的水位，同時避免影響到後端系統對外提供服務。