負載測試和壓力

負載測試和壓力

1）為什麼需要它

• 確認容量（在給定SLO下系統將承受多少RPS/競爭性會話）。
• 查找瓶頸（CPU/IO/DB/網絡/鎖定/池）。
• 在CI/CD中設置性能預算和「門」。
• 降低發布風險（p95/p99回歸,高峰時錯誤增加）。
• 計劃容量/成本（滑出和儲備）。

2）Perf測試的類型

負載（工作負載）：逼真的流量接近峰值；SLO驗證。
Stress（壓力）：高達/高於極限→降解行為發生故障。
Spike（脈沖）：快速的負載跳躍→彈性/自動軌跡。
Soak/Endurance（延長）：小時/天→泄漏，碎片，漂移延遲。
能力/可變性：在尺度輸出時如何通過輸入/延遲變化；阿姆達爾/古斯塔夫森定律。
Smoke perf：每個發行版（表演三位一體）上的簡短「煙霧」運行。

3）交通生成模型

封閉模型（固定的VUs/concurrency）：「N」用戶，每個用戶在客戶端中排隊查詢→隊列。隱藏過載的風險。
開放模型（arrival rate）：與現實生活中一樣,λ強度的應用程序流（req/s）。更適合公共API。

Little定律：「L=λ × W」。
對於池/服務：最小並發性≈ 'λ × W'（添加20-50%的庫存）。
其中「λ」是通過輸入，「W」是平均維護時間。

4）負載配置文件和腳本

User journey mix：腳本份額（登錄,瀏覽,deposit, checkout……）。
思考時間：用戶暫停（分布：指數/lognormal）。
數據配置文件：響應大小、付費、參數變異性。
相關性：將步驟（cookies/tokens/ID）鏈接為真實的浮動。
冷/熱/熱kesh：單獨運行。
Read vs Write：讀數/記錄的平衡,retrais的等效性。
多區域：RTT，POP/ASN分布。

5）測試環境

隔離：通過拓撲/設置（但不是「byom 」prod）接近展位。

數據： PII掩蔽,卷,索引如銷售.

負載發生器：不靠在CPU/網絡上；分布式收發器，時間同步。
可觀察性：度量/treas/Logs，周邊合成，CPU/heap配置文件導出。

6）度量標準和SLI

Throughput：每秒RPS/事務。

Latency: p50/p95/p99, TTFB, server time vs network.

錯誤：5xx/4xx/域錯誤的百分比。
Aturation： CPU, load avg, GC, Disk IOps/潛伏期, network, pool wait。
業務SLI：成功存款≤ 5 s，訂單確認≤ 2 s。

從SLO中獲取閾值（例如"99。95% ≤ 300 ms"），在運行過程中監控燃燒率。

7）尋找瓶頸（技術）

1.將系統穩定預熱到60-80%的目標負載。
2.增加步驟（ramp） →固定p95/p99和error-rate生長的位置。

• 在池中排隊（DB/HTTP），
• WAIT/locks（DB）的增長，
• GC暫停/跳躍，
• 網絡retransmits/packet loss，
• 磁盤隱含性/緩存錯誤。
• 4.本地化：二進制查詢路徑搜索、分析儀（CPU/alloc/lock-profile）。
• 5.固定「瓶子」→調整→重復運行。

8）壓力下的行為

Graceful degradation：極限,電路斷路器,隊列與後壓,模式「被接受處理」。
Retrai：最多1個，僅偶數；jitter；中繼預算≤ RPS的10％。
失敗打開/失敗關閉：對於非關鍵依賴項,允許失敗打開（kesh/存根）。
Cascading failure：隔離池/配額（bulkhead）,快速定時,「平穩」禁用功能（功能頁）。

9）工具（按任務選擇）

k6 （JavaScript, open/open-model,快速,方便使用CI）。
JMeter（生態系統豐富，GUI/CLI，插件，但較重）。
Gatling（Scala DSL，高性能）。
位置（Python，腳本靈活性）。
Vegeta/hey/wrk（微型基準和快速驗證）。

規則：一個「主要」工具+輕量級CLI用於公關中的煙熏。

10）示例（snippets）

10.1 k6（帶有arrival rate的開放模型）

js import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
scenarios: {
open_model: {
executor: 'ramping-arrival-rate',
startRate: 200, timeUnit: '1s',
preAllocatedVUs: 200, maxVUs: 2000,
stages: [
{ target: 500, duration: '5m' },  // до 500 rps
{ target: 800, duration: '5m' },  // стресс
{ target: 0,  duration: '1m' }
]
}
},
thresholds: {
http_req_duration: ['p(95)<300', 'p(99)<800'],
http_req_failed: ['rate<0.005'],
},
};

export default function () {
const res = http.get(`${__ENV.BASE_URL}/api/catalog?limit=20`);
sleep(Math.random() 2); // think-time
}

10.2 JMeter（配置文件想法）

Thread Group + Stepping Thread или Concurrency Thread (open-like).

HTTP Request Defaults, Cookie Manager, CSV Data Set.

Backend Listener → InfluxDB/Grafana;按時間/代碼排序。

10.3 Locust (Python)

python from locust import HttpUser, task, between class WebUser(HttpUser):
wait_time = between(0.2, 2.0)
@task(5)
def browse(self): self.client.get("/api/catalog?limit=20")
@task(1)
def buy(self): self.client.post("/api/checkout", json={"sku":"A1","qty":1})

11）數據、相關性、準備

種子數據：目錄，用戶，資產負債表，代幣-如銷售。
偽裝/匿名PII；在實際分布之上生成合成物。
相關性：從響應（RegExp/JSONPath）中檢索ID/令牌,並在後續步驟中使用。

12）運行期間的觀察力

沿途的RED dashbords（Rate，Errors，Duration）。
Exemplars：從指標過渡到軌道（trace_id)。
錯誤日誌：sampling+聚合,復制/等效性。
系統：CPU/GC/heap，驅動器/網絡，池等待。
DB：頂級查詢，鎖定，索引掃描，bloat。

13）自動化和表演門

CI：在急流中短暫運行（例如k6 2-3分鐘）。
Nightly/Weekly：在單獨的環境中漫長的soak/stress；報告和趨勢。
金絲雀發行：將SLO（錯誤率，p95）分析為促銷活動的「門戶」。
回歸：基線vs當前法案；惡化時的異常值>X%。

14）容量規劃和成本

曲線throughput→latency：定義knee point（膝蓋）-之後,p99會急劇增長。
滑出：測量縮放效率（RPS增量/節點增量）。
費用：「RPS每小時」，高峰事件備用+DR備用。

15）反模式

在「空白」環境中進行無控制的prod擊球或測試，與prod不同。
帶有固定VU的封閉模型，可隱藏過載。
缺乏思考時間/數據→不切實際的kesh命中，反之亦然-風暴到原始人。
單個「/ping」腳本代替自定義的flow。
缺乏可觀察性：「只看到RPS和平均延遲」。
不受控制的後退→ DDoS。
在不提交假設/更改的情況下混合測試和優化。

16）支票清單（0-30天）

0-7天

定義SLI/SLO和目標流量配置文件（mix, think-time,數據）。
選擇工具（k6/JMeter/Locust）,舉起RED行列板。
準備展位和種子數據,禁用第三方限制/captchi。

8-20天

構建腳本：開放模型（arrival rate），冷/熱/熱kesh。
啟動load → stress → spike；修復刀尖和瓶頸。
在CI（微運行）中引入性能門。

21-30天

Soak測試4-24小時：泄漏/漂移GC,穩定。
記錄極限、容量計劃、「RPS→p95/oshibki」插圖。
準備「如何增加限制/滑板」和「如何降級」的運行手冊。

17）成熟度量

有現實的配置文件（混合，思考時間，數據）覆蓋≥ 80％的流量。
RED-dashbords+跟蹤已連接至所有測試。
在p95回歸/錯誤時，表演門會阻止發布。
容量和knee點記錄在關鍵服務上。
每月soak/stress運行和動態報告。
自動滑軌和缺少cascade-fail證實了對「spike」的抵抗力。

18）結論

負載測試是常規的工程實踐，不是一次性的「測量」。模擬實際用戶（開放模式）,測量客戶體驗（SLI/SLO）的反映,在CI/CD中保持可觀察性和「網關」,進行stress/spike/soak運行並捕獲knee點。然後將峰值事件和「黑天鵝」轉換為可管理的腳本，並將性能轉換為可預測和可衡量的平臺參數。