負載和壓力測試
1）術語和目的
Load test-針對SLO（例如p95 <200 ms, error rate <0）的工作範圍驗證（目標RPS/競爭性）。5%).
Stress測試-超出範圍（在CPU/DB/網絡飽和度之前）、降解觀察和還原力學。
Spike測試-劇烈的負載爆發（分鐘內× N）。
Soak/Endurance是用於查找泄漏，GC漂移，碎片，排隊的時間較長（小時/天）。
能力測試-計算吞吐量（飽和點）和庫存的高原。
目標：確認SLO，修復高原，了解瓶頸，校準自動縮放和限制。
2）交通模式： 開放vs封閉
封閉模型（concurrency-driven）：固定數量的虛擬用戶（VUs）,每個虛擬用戶在響應後都會進行思考。
開放模型（arrival-rate）：獨立於響應的固定請求到達強度（RPS）。
Little’s Law: `L = λ W`
「L」是同時服務的請求的平均數量，
'λ'-強度（RPS）,
「W」是平均響應時間。
因此，評估發電機所需的競爭性：'concurrency ≈ target_RPS p95_latency'。
3）度量： 我們測量什麼
SLI延遲：p50/p90/p95/p99和尾巴p99。9;分別用於「熱」和「冷」路徑。
錯誤：'5xx'，'4xx'（有效性/非有效性），timeouts，aborted。
吞吐量：穩定的RPS,通過流/字節。
資源：CPU，RAM/heap，GC停頓，磁盤IOPS/lat，網絡bandwidth，連接數/FD。
隊列和逆向器：深度，等待時間，shed/限量查詢數量。
緩存效率：命中/小姐，熱量風暴。
DB/緩存/隊列：p95查詢，鎖定，沖突，池實用化。
4）展位和數據
配置等效性：軟件版本,限制（uLimit, conntrack）, JVM/GC配對,池。
拓撲：LBs，CDN，WAF，TLS和相同的網絡「hops」。
數據：現實分布（物體大小，熱鍵/冷鍵，區域）。
冷熱/熱起步：單獨運行；一定要測試「冷」緩存。
背景隔離：禁用無關的喬巴/克羅諾瑪或考慮其效果。
5）腳本（負載配置文件）
1.基線：逐步加速到目標RPS，保持10-30分鐘。
2.Ramp＆Hold：平穩增長至X％高於目標，保持→尾巴分析。
3.Spike：瞬間× 2- × 5飆升1-5分鐘，然後返回。
4.對失敗的束縛：失敗前的步驟；捕獲第一個SLO未完成點和斷點。
5.Soak：6-24小時，交通變化（白天/夜晚），跟隨葉子/漂移。
6.混合：按實際分布（Zipf/pareto）混合的末端，重量不同。
6）循序漸進的過程
定義SLO和目標流量配置文件。
選擇負載模型（打開/關閉）,設置arrival-rate或VU。
準備數據和「熱「/」冷」模式。
設置遙測（traces/Metrics/Logies）,與測試傷口共振。
熱身和奔跑，工件收集（CPU/heap配置文件，flame graphs，explain/slow-logs DB）。
瓶頸分析，行動項目的形成。
小說後Reprogon，基線更新和capacity劇本。
7）瓶頸和典型小說
CPU-bound服務：分析→消除熱功能，變異，分支；向量化，高速緩存友好結構。
網絡/TLS：保持活力，HTTP/2/3，連接池，正確的計時器，減少閑聊。
DB：索引、戰鬥、準備好的查詢、連接池、R/W分離、結果緩存、重復數據消除查詢。
緩存：大小，TTL，要求緩存，防風暴，扭曲，區域球。
隊列/經紀人：接待限制/並發限制，蹦床尺寸，偶發消費者，DLQ天花板。
Garbatedge/暫停：調節GC,租用緩沖區,在合理範圍內進行對象填充。
I/O/驅動器：異步I/O、壓縮、響應壓縮和合理水平。
8）限制和保護
Budget taymauts：從上到下避開級聯。
利率限制/令牌罐：可預測的退化而不是「長期死亡」。
電路斷路器和低優先級著色器在飽和時。
Backpressure：深入鏈中的信號和並發約束。
Bulkheads：將池隔離在關鍵的端點下。
Idempotency：在後臺安全重播的鑰匙。
9）工具以及何時選擇
k6是簡潔的JS，對arrival-rate，集成和圖形的出色支持。
Gatling-Scala DSL，高性能發電機。
JMeter是一個靈活，豐富的生態系統。適用於協議/插件。
Locust-Python腳本,適用於復雜的用戶流邏輯。
Vegeta/hey/wrk-HTTP上的微生物和點運行。
tc/netem, toxiproxy-註入網絡降解。
Flamegraph/profiler-搜索CPU/heap的「熱點」。
10）示例（草圖）
k6（開放模型，混合殘局）
javascript import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
scenarios: {
open_model: {
executor: 'constant-arrival-rate',
rate: 800, timeUnit: '1s', duration: '20m',
preAllocatedVUs: 500, maxVUs: 2000
}
},
thresholds: {
'http_req_duration{kind:hot}': ['p(95)<200'],
'http_req_failed': ['rate<0. 005']
}
};
export default function () {
const r = Math. random();
let res;
if (r < 0. 6) {
res = http. get('https://svc/api/hot', { tags: { kind: 'hot' }});
} else if (r < 0. 9) {
res = http. get('https://svc/api/warm', { tags: { kind: 'warm' }});
} else {
res = http. post('https://svc/api/heavy', JSON. stringify({ n: 1000 }), { headers: { 'Content-Type': 'application/json' }});
}
check(res, { 'status is 2xx': (r) => r. status >= 200 && r. status < 300 });
sleep(0. 2);
}Gatling（臺階和尖峰）
scala setUp(
scn. inject(
rampUsersPerSec(50) to 500 during (10 minutes),
constantUsersPerSec(500) during (20 minutes),
spikeUsers(2000). during(30. seconds)
)
). protocols(http. baseUrl("https://svc"))負載計劃（YAML骨架）
yaml profile: "mix-traffic"
targets:
- endpoint: GET /api/hot weight: 0. 6
- endpoint: GET /api/warm weight: 0. 3
- endpoint: POST /api/heavy weight: 0. 1 schedule:
- step: { rps: 300, hold: 10m }
- step: { rps: 600, hold: 10m }
- step: { rps: 900, hold: 10m }
guardrails:
slo:
p95_ms: 200 error_rate: 0. 5%
abort_if:
- metric: error_rate op: ">"
value: 2%
window: 2m11）自動化和生命周期
每個PR中的perf-smoke（關鍵尾礦的短運行）。
夜間「capacity」牛排運行，帶有報告和配置文件工件。
CI/CD中的門戶：在p95/p99> X%回收基線或錯誤率上升時的票據失誤。
基線旋轉並存儲輪廓/長笛圖作為人工制品。
相關性標簽：覆蓋了哪些服務/終點,使用了哪些流量配置文件。
12）反模式
一臺機器上的發電機和測試服務→扭曲的結果。
僅適用於API後退的封閉模型（VUs）→尾巴低調和不正確的分數。
在空的DB/緩存上運行，沒有冷啟動。
沒有現實的分配（所有請求都是相同的）。
沒有遙測（只有發電機側面的RPS/latency）。
沒有穩定基線和環境控制的比較。
通過放大的taymout「優化」而不是糾正原因。
13）建築師支票清單
1.是否定義了SLO和類型/峰值負載?
2.選擇了正確的模型（打開/關閉）,並繪制了流量配置文件?
3.展位等同於configs和拓撲,有冷熱模式嗎?
4.包括遙測和配置文件，是否設置測試傷口標簽？
5.運行： baseline/ramp/spike/stress/soak-覆蓋?
6.確定飽和點，並計劃存貨（安全margin）？
7.設置了極限、斷路器、逆沖器、idempotency、著色保單?
8.在p95/p99倒退和error rate上有CI門,基線是否旋轉?
9.小說之後-回放和劇本的電源更新？
10.記錄了自動縮放和緊急模式的計劃?
二.結論
負載和壓力測試不是一次性的「競賽」，而是持續的工程實踐。CI/CD中逼真的流量模型，正確的展位，遙測和自動化將性能從「神秘魔術」轉換為指標驅動的能力：你知道你的上限在哪裏，庫存有多安全，以及哪些變化真正改善了用戶的體驗。