負載測試和壓力配置文件
簡短摘要
負載測試是在現實和極端情況下對性能和穩定性的系統測試。成功的基礎是：正確的流量模型（open vs closed），SLO記錄，凈度量（latency/throughput/錯誤/飽和），代表性數據，自動化和可重復性。結果不是「RPS數字」，而是解決方案：瓶頸在哪裏，性能成本多大，故障閾值在哪裏以及如何移動它。
SLO/SLI和目標指標
SLO（示例）：p95 API ≤ 250毫秒，p99 ≤ 600毫秒；錯誤≤ 0。3%/30天。
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
錯誤和飽和觸發器（例如CPU> 75％或queue depth> X →降解）。
測試類型
1.Baseline/Benchmark-單一服務/終端，「完美」條件。
2.Load是一個現實的「工作日」+ramp-up/ramp-down。
3.Stress-在降解和固定斷點之前增加負載。
4.Spike-突然飛躍（秒/分鐘內為x2-x10）。
5.Soak/Endurance-長運行（8-72小時）：內存泄漏,潛伏漂移。
6.Capacity是用於構建性能曲線和容量規劃的階梯式負載。
7.Degradation/Chaos-mix-負載+部分故障（延遲的DB，緩存下降，「鋸齒狀」單元）。
流量模型： Open vs Closed
開放模型（對於互聯網更逼真）：用戶具有λ強度（類似於Poisson的流）。如果系統制動，則查詢會累積而不是「凍結」。
Closed model：固定數量的虛擬用戶（VU）,帶有思考時間。隨著延遲的增加，RPS會人為下降-仔細觀察結論。
建議：對於前端API,請使用open model （k6'arrival-rate"）,對於內部同步腳本-與closed組合。
負載配置文件（模板）
「正常日子」：基本背景+日振蕩。
「高峰活動」：起點（加熱）前的10-30分鐘，起點，高原，尾巴的尖銳尖峰。
「比賽/流」：步伐森林，間隔重復高峰。
「基礎架構退化」：半緩存為空,一個區域關閉,PSP潛伏期增加。
「Failover」：流量以1-5分鐘流入儲備；我們檢查自動滑板/HPA/回歸風暴。
數據和環境準備
測試數據：現實的基數（提供商，貨幣，國家），「骯臟」字段，請求分配（Pareto/Zipf）。
秘密/PII：匿名；keys/PSP-sandbox。
環境：專用perf展位,與集成隔離（mock/stabs）,固定版本。
可觀察性：度量（Prometheus），logi（Loki/ELK），路線（OTel）。在回復中捕獲build id。
Retrae的抗風暴和偶然性
Retrai僅用於等效操作；設置一個重復的預算（例如,≤流量的10%）。
Exponential backoff + jitter;「拼接」相同的GET。
對於付款-等效密鑰和顯式狀態。
Thundering herd防護：緩存鎖、SWR、本地信號燈。
工具和模式
k6（腳本，開放模型，良好的報告），Locust（Python腳本），Gatling（Scala），JMeter（各種協議）。
協議：HTTP/1。1/2/3, gRPC, WebSocket, TCP/UDP;服務器-push不要測試「像GET一樣」。
流量生成： 水平縮放發電機,控制網絡瓶頸.
我們吃掉配置文件：pprof/async-profiler/ebpf在負載下,路線為OTel。
迷你示例k6（開放模型+spike）：javascript import http from 'k6/http';
import {check, sleep} from 'k6';
export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};
export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}執行方法
1.假設→可能存在哪些瓶頸（CPU，DB，緩存，網絡，TLS，GC）。
2.配置文件→腳本/路由、流量份額、模型（打開/關閉）和數據。
3.加熱→ 緩存/連接/TLS/解釋器。
4.將→階段提高到目標強度。
5.高原→收集穩定的指標和步道。
6.壓力/衰退→尋找斷點，觀察自動滑行。
7.分析→指標相關性、flamegraph、報告和變更計劃。
8.Repruf →通過CI（Regression Perf）管線重播。
成果分析
「負載→延遲/錯誤」曲線：尋找膝蓋（capacity）。
斷開潛伏期：網絡（DNS/TLS/connect），代理程序，應用程序，DB，外部調用。
Saturation： CPU> 75-85%, GC pause> p95, I/O期望,任務隊列。
彈性：自動軌道的反應時間（HPA/KEDA），「冷啟動」，緩存加熱。
費用：$/1000 RPS按目標SLO,高峰預算預測。
工程實踐
降解指標：p99的「尾巴」，隊列生長，命中率下降，回避嘗試增加。
排除用戶：文件描述符限制、sysctl、conn-pool、「reuseport」、TLS鏈、OCSP。
DB：索引/計劃/查詢緩存，連接池，對接操作，每個執行器的後壓。
緩存：大小/事件策略、熱鍵、復制。
網絡/邊緣：HTTP/2/3, resumption≥70%, Brotli,高速緩存CDN密鑰,tiered緩存。
負載下的可觀察性
標準：系統（CPU/mem/IO），運行時間（GC/heap），網絡（RTT/loss/ECN），L7（p95/99，5xx/429），隊列，DB/緩存群集。
Traces：在「尾巴」（基於尾巴）上啟用采樣,標記build id/canaries。
Logs：有體積限制的錯誤聚合（不是「forDOS或」log-pipline）。
實驗：功能橫幅和configs必須記錄在報告中。
自動化和CI/CD
CI的Perf-jobs（smoke 3-5 min，nightly 30-60 min，weekly soak）。
公差邊界：潛伏期/錯誤/資源→在回歸時「打破法案」。
工件：圖形，flamegraphs，配置文件，JSON報告（k6/jtl）。
數據和腳本的驗證，perf腳本的PR評論。
iGaming/fintech的細節
比賽/比賽：spike+plateau；TLS/DNS/CDN加熱，提高池限制，機器人的「灰色」路由。
付款/PSP：沙盒限制，等效性，嚴格的計時器；degrade模式檢查（參考書緩存、隊列）。
頭獎/榮譽：原子性和一致性，無雙，RNG/領導板負荷。
Antifrod/AML： 規則負載/ML評分、後壓、事件重復數據消除。
監管：在高峰時編寫指標和版本,報告進行審核。
啟動清單
- 記錄了SLO/SLI和「紅線」（錯誤/潛在/飽和）。
- 腳本和負載配置文件已獲得批準（打開/關閉,spike/soak/stress）。
- 數據是真實的，PII是偽裝的，集成是sandbox/mock。
- 可觀察性準備就緒：度量/預告/記錄,發布標簽。
- 系統的configs （ulimit/sysctl/pools）已被記錄下來。
- 自動滑行/緩存加熱計劃和滾回標準。
- 閾值差和命令通信計劃（呼叫）。
- 報告模板（圖表、結論、行動）已準備就緒。
典型錯誤
封閉模型測試會產生「綠色」結果，並且prod會下降（不能忽略開放模型）。
非代表性數據（一種貨幣/一種提供者）→錯誤的結論。
零準備：冷緩存/TLS/連接器 →啟動時過度潛伏。
沒有限制的retrai →風暴和級聯下降。
所有服務都有相同的配置文件→跳過真正的「熱點」。
不存在soak運行→內存泄漏和漂移。
不透明的結果：沒有軌道/長笛圖→無法定位瓶頸。
迷你花花公子
確定極限吞吐量（斷點）
1.每5-10分鐘10-20%負載的步驟2）捕捉到p95急劇增長和錯誤>SLO的時刻。3）我們刪除CPU/DB/緩存配置文件。4）優化計劃和重播。
遏制暴風雨retrais
1.限制retry-budget並啟用backoff+jitter。2）引入request-collapsing/SWR。3）允許「degrad模式」（功能受限）。4）重新檢查冪等性。
高峰活動（錦標賽）-前期計劃
1.加熱CDN/DNS/TLS/池。2）增加目標HPA，收獲儲備。3）機器人的單獨限額。4）尖峰模式大橋，呼叫通信橋。
Soak之夜
1.8-12小時穩定負載。2） 監控頭部/FD/conn/GC-pauses。3）鉆探delta p95和命中率。4）固定泄漏和漂移。
結果
負載測試是工程決策過程而不是「RPS競賽」。模擬真實的配置文件（尤其是開放模型）,捕獲SLO,拍攝指標和軌跡,尋找性能的膝蓋,並計算性能成本。自動化運行，保持反風暴的撤退，並計劃高峰事件-因此該平臺在最繁忙的時刻將是可預測和可持續的。