负载和压力测试
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中逼真的流量模型，正确的展位，遥测和自动化将性能从"神秘魔术"转换为指标驱动的能力：你知道你的上限在哪里，库存有多安全，以及哪些变化真正改善了用户的体验。