负载测试和压力配置文件
简短摘要
负载测试是在现实和极端情况下对性能和稳定性的系统测试。成功的基础是：正确的流量模型（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,拍摄指标和轨迹,寻找性能的膝盖,并计算性能成本。自动化运行，保持反风暴的撤退，并计划高峰事件-因此该平台在最繁忙的时刻将是可预测和可持续的。