基准与压测

• Gatling 场景定义
• 负载注入模型
• 并发与调节

Gatling 基于 Scala DSL 定义负载场景，负载建模包括：1) 场景（scenario）：定义用户行为流程（HTTP 请求、断言、数据提取）；2) 注入模型（injection）：用 inject 定义负载注入方式，如 rampUsers(1000).during(10s)（10 秒内渐增 1000 用户）、constantUsersPerSec(100)（每 100 用户/秒持续）、atOnceUsers(100)（一次性 100 用户）、constantConcurrentUsers（固定并发）；3) 协议（protocol）：HTTP 配置（baseUrl、headers、超时）；4) 断言（assertions）：对响应时间分位、错误率、吞吐断言。Gatling 用异步 IO 实现高并发，负载建模灵活，可组合 ramp/constant/step 等注入模式模拟真实流量波动。结果报告含 RPS、响应时间、分位、错误率。

Gatling 负载建模核心是场景 + 注入模型。理解各种注入方式（ramp/constant/step）可模拟真实负载形态。

• Locust 协程并发模型
• 分布式压测
• 结果分析与容量规划

Locust 基于 Python 协程（gevent）实现并发，单个 worker 可承载大量并发用户（比线程模型更高），无需大量线程。分布式压测组织：master 节点 + 多个 worker 节点，master 分发任务、聚合结果，worker 执行并发用户，通过 locust -f locustfile.py --master / --worker 启动，可横向扩展压测能力。负载建模用 @task 定义用户行为，user_classes 定义用户数。结果分析：RPS（吞吐）、响应时间分布（均值、p50/p95/p99）、错误率、并发数。容量规划：根据 RPS 与响应时间分位找出系统瓶颈（S 曲线拐点），确定最大可支撑并发与 QPS，结合生产流量预测扩容；p99 反映尾延迟，用于延迟 SLA 规划。结果指导容量与扩容决策。

Locust 协程模型高并发、分布式扩展。结果分析的 RPS 与分位指导容量规划，是容量评估的关键。

• k6 脚本与执行
• 分布式执行
• 与 JMeter/Gatling 差异

k6 用 JavaScript 编写压测脚本（import http from 'k6/http'; export default function() {...}），定义场景、负载（export const options = { scenarios: {...} }）、断言（阈值 checks/trends）。k6 的执行模式：本地单机（CLI 运行）、集群执行（k6 Cloud 或分布式编排，多实例聚合结果）、与 CI 集成（k6 支持 thresholds 作为性能门禁）。与 JMeter/Gatling 的定位差异：k6 轻量、脚本简单（JS）、原生支持负载模型与阈值、Cloud 化、适合 CI/CD 集成与持续性能测试；JMeter 功能全、生态大、GUI，适合复杂协议与手工脚本；Gatling 基于 Scala DSL、报告丰富、面向开发者。k6 定位"开发者友好的持续压测与 CI 集成"，JMeter/Gatling 定位"传统综合压测"。选择取决于场景复杂度与集成需求。

k6 适合 CI 持续压测，JMeter 功能全，Gatling 开发者友好。理解差异按场景选型。

• 环境差异
• 结果换算
• 容量推断

压测环境与生产环境存在差异，影响结果换算：1) 硬件：CPU 核数/主频、内存、磁盘类型（SSD/HDD）不同，压测结果不能直接套用生产，需按硬件能力比例换算；2) 网络拓扑：压测机与目标机的网络延迟、带宽、是否同机房影响 RT 与吞吐，需按网络延迟换算；3) 数据规模：压测数据量（表行数、缓存命中率）影响查询性能，需构造与生产规模相近的数据；4) 并发与负载差异。换算思路：压测结果作为"单机/单环境基准"，结合生产硬件倍率、网络系数、数据规模因子估算生产容量；或直接在生产影子环境/全链路压测验证。核心是"压测是近似，需结合系数与环境差异校准，不能直接等同"。

环境差异使压测结果需换算校准。理解硬件/网络/数据差异的影响系数，是正确推断生产容量的关键。

• @CompilerControl 编译控制
• @Fork 进程隔离
• @Measurement 测量配置

JMH 的 @CompilerControl 控制 JIT 编译行为（如 DONT_INLINE/INLINE/EXCLUDE 强制内联/禁用内联/排除方法），用于消除编译优化的干扰或验证特定编译行为。@Fork 指定基准运行在多少个独立 JVM 进程中（每个 fork 独立进程，隔离 JIT 与 GC 状态），默认 5 个 fork，用于统计稳定性与消除进程间干扰。@Measurement 配置测量参数（iterations 迭代次数、time 每次迭代时长、batchSize 每批调用数），控制测量精度与时长。三者的作用：@CompilerControl 控制编译、@Fork 隔离进程、@Measurement 控制测量精度。理解它们能正确配置 JMH 基准以获得可信结果。

@CompilerControl 控制编译，@Fork 隔离进程，@Measurement 控制测量。理解三者是配置可信 JMH 基准的关键。

• @Param 参数化
• 多参数维度
• 用法

JMH 的 @Param 注解用于参数化基准，为基准方法提供多个参数值，JMH 会为每个参数组合运行单独的基准。用法：@Param({"1", "10", "100"}) int size; 在基准方法中引用 size，JMH 自动为 1/10/100 各运行一次基准。@Param 支持多个 @Param 字段（多参数维度），JMH 生成各参数组合的笛卡尔积，分别测量。用途：评估不同参数规模（数据量、并发、大小）下的性能，识别性能随参数变化的趋势。多参数基准通过 @Param 组合实现，是 JMH 参数化测试的核心。

@Param 提供多参数基准，自动为各参数组合运行测量。理解参数化与组合是本问题的核心。

• Fork 隔离
• MeasurementBatchSize
• Threads 并发

JMH 的 @Fork 用于进程隔离（每个 fork 独立 JVM，隔离 JIT/GC/类加载状态），提高结果稳定性与可信度；@Measurement(batchSize=...) 设置每批调用次数（MeasurementBatchSize），用于标记"每批执行的操作数"，影响 @OperationsPerInvocation 与吞吐统计；@Threads 设置基准运行的线程数，用于测量并发/多线程场景下的性能（如并发吞吐、竞争）。工程价值：Fork 保证结果不受单次 JVM 状态偶然影响；batchSize 控制批处理基准的统计语义；Threads 评估并发扩展性。三者结合能配置可信、覆盖并发场景的 JMH 基准。

Fork 隔离提升可信度，batchSize 控制批统计，Threads 评估并发。理解三者工程价值是配置 JMH 的关键。

• GC profiler
• Stack profiler
• Classloader profiler

JMH 内置 Profiler 用于基准运行时的剖析：1) GC profiler（-prof gc）：报告基准运行期间的 GC 活动（分配速率、GC 次数、GC 时间），用于评估基准的 GC 影响与内存分配；2) Stack profiler（-prof stack）：采样调用栈，定位基准内热点方法（CPU 热点）；3) Classloader profiler（-prof classloader）：监控类加载/卸载，评估基准的类加载行为；4) 其他如 perfasm（汇编）、async（async-profiler）、jfr（JFR 事件）。工程价值：JMH 不仅测吞吐/延迟，还通过 profiler 剖析基准的 GC、热点、类加载，定位性能瓶颈。理解各 profiler 用途可深入分析基准结果。

JMH Profiler 提供 GC/栈/类加载剖析，深入基准性能。理解各 profiler 用途是深度分析基准的关键。

• wrk 特点
• ab 特点
• vegeta 特点

HTTP 基准工具：wrk 用 C 实现 + Lua 脚本，高并发（基于 epoll 高性能）、支持线程与连接数、Lua 自定义请求，适合快速吞吐/延迟压测；ab（ApacheBench）简单易用，单请求压测，适合快速基线，但并发能力有限；vegeta 用 Go 实现，支持固定速率（RPS）注入、可编程、结果格式化，适合持续压测与 CI 集成。选择：wrk 高并发吞吐压测、ab 快速简单、vegeta 固定速率与持续压测。它们都是 HTTP 层压测，适合 Web 服务快速基准；复杂场景（多协议、业务流）用 JMeter/Gatling/k6。理解各工具定位与适用场景是选型关键。

wrk/ab/vegeta 各有特点（高并发/简单/固定速率）。理解差异按压测目标选择 HTTP 基准工具。

• QPS 与 RT
• 分位与错误率
• 线程/连接数关系

压测指标：QPS（吞吐，每秒请求数）与 RT（响应时间）相关，利特尔定律 QPS = 并发数 / 平均 RT；RT 分位（p50/p95/p99）反映延迟分布，p99 是尾延迟（高并发场景关键）；错误率反映失败比例（超时、5xx）。线程数/连接数关系：并发数增加 → 系统负载上升 → RT 上升 → 在某个点（拐点）后 QPS 不再增长（饱和），RT 与错误率急剧上升。分析：QPS 饱和点决定最大容量；p99 与错误率反映稳定性；线程/连接数过多导致资源竞争（线程切换、连接排队）降低 QPS。解读重点是"找到 QPS 与 RT 的拐点"与"并发-延迟-错误率的关系"，指导容量与并发配置。

QPS/RT/错误率与并发的关系是压测解读核心。找到饱和拐点与尾延迟是容量评估的关键。

• 预热必要性
• 并发模型
• 平均 vs 分位

压测结果可信度受预热、并发模型、指标统计影响：1) 预热：应用未预热（JIT 未就绪、缓存未填充）时性能不稳定，需预热到达稳态再测量，否则结果偏低且波动；2) 并发模型：闭合模型（固定并发）vs 开放模型（固定速率）影响排队与尾延迟记录，coordinated omission 会低估尾延迟；3) 指标统计：平均 RT 会被极端值掩盖，分位（p50/p95/p99）更能反映真实分布与尾延迟；只看平均会高估性能。提升可信度：预热充分、选择正确并发模型、用分位指标 + 多次重复 + 置信区间。核心是"稳态测量 + 分位统计 + 控制变量"。

预热、并发模型、分位统计决定了压测可信度。理解这些因素才能获得可信的压测结果。

• 压测工具瓶颈
• 网络瓶颈
• 应用/数据库瓶颈

压测瓶颈逐层定位：1) 压测工具：先确认压测工具自身是否瓶颈（单机并发限制、工具 CPU 饱和），若工具先饱和则需分布式压测；2) 网络：检查网络带宽、延迟、连接数，确认是否有网络瓶颈（抓包、观察吞吐）；3) 应用线程：用 jstack/JFR 看应用线程状态（线程池耗尽、阻塞、CPU 繁忙），确认应用层瓶颈；4) 数据库连接：检查连接池是否耗尽（连接池大小、等待）、SQL 慢查询；5) 锁：剖析锁竞争（lock profiling），确认锁瓶颈。逐层排查"瓶颈在哪一层"，用工具（压测工具监控、网络监控、jstack、DB 监控、profiler）分别定位，层层下钻直到找到根因。每层都有对应诊断手段。

瓶颈逐层定位（工具→网络→应用→DB→锁）是系统化方法。理解各层诊断手段是定位压测瓶颈的关键。

• 压测与生产校准
• 能力映射
• 容量推断

压测结果与生产指标协同校准：1) 对比压测 QPS/延迟与生产监控（真实 QPS、延迟、资源使用），验证压测模型是否贴近生产；2) 用生产监控的基线（CPU/内存/延迟/GC）校准压测环境差异（硬件、网络、数据），修正压测结果；3) 用生产真实流量模式（峰值、并发分布）调整压测负载模型。压测到生产的能力映射：1) 确定压测环境的单机能力（QPS/并发）；2) 用生产硬件倍率（CPU 核数、内存）、网络系数、数据规模因子换算生产容量；3) 结合生产监控的利用率（如生产 CPU 平均 40%）推断可承载能力与扩容需求；4) 用影子/全链路压测在生产环境验证。核心是"压测基准 + 环境系数 + 生产监控校准"。

压测与生产校准通过环境系数与生产监控修正。能力映射是"压测基准 + 系数换算 + 生产验证"。

• JMH 与 GraalVM
• Native Image 基准
• 协作方式

JMH 与 GraalVM 的协作：1) 在 GraalVM JVM（HotSpot）上运行 JMH 基准，可测 Graal 编译器（GraalVM 的 JIT）下的性能；2) 为 GraalVM Native Image 基准：把 JMH 基准编译为原生可执行文件运行（Native Image 支持 JMH，通过 -H:+GraalOptimization 等），对比 JVM 与 Native 模式性能；3) 用 -XX:+UseJVMCICompiler 启用 Graal JIT 对比 C2。协作价值：评估 GraalVM 的 JIT 优化（Graal 编译器）与 Native Image 的 AOT 性能，用于选型（JVM vs Native）。注意：Native Image 的 AOT 编译后，JIT 特性（如分层编译）不适用，基准语义需调整；JMH 在 Native Image 下需正确配置（AOT 反射等）。理解 JMH 与 GraalVM 协作可科学评估 GraalVM 方案。

JMH 用于评估 Graal JIT 与 Native Image 性能对比。理解 JVM 模式与 Native 模式的基准差异是关键。

• 各工具适用场景
• 分布式压测
• 选型

压测工具选型：JMeter 功能全、协议多（HTTP/JDBC/JMS）、GUI + 脚本、生态大，适合复杂场景与手工综合压测；wrk 轻量高并发（C/Lua），适合快速 HTTP 吞吐压测；Gatling 基于 Scala DSL、异步高并发、报告丰富，适合开发者与复杂场景；k6 基于 JS、轻量、CI 友好、云化，适合持续压测与 CI 集成。分布式压测：JMeter 支持 master-slave 分布式；Gatling 支持集群注入；k6 支持集群/Cloud 分布式；wrk 通常单机（可多实例）。选型依据：场景复杂度（简单 HTTP 用 wrk/k6，复杂协议用 JMeter）、集成需求（CI 用 k6）、开发风格（Scala 用 Gatling）、生态（JMeter）。分布式压测用于超大规模并发，需规划节点与聚合。

工具选型按场景复杂度、集成需求、开发风格。分布式压测用于超大规模，理解各工具能力是关键。

• 同步线程模型
• 异步 IO 模型
• 吞吐影响

压测工具的线程模型影响其吞吐上限：同步线程模型（如 JMeter 默认、ab）每个并发用户占用一个线程，线程数受限于内存与线程切换开销，单机可承载并发有限（数千），高并发时线程切换成为瓶颈，吞吐受限。异步 IO 模型（如 Gatling、k6、wrk、Locust 协程）用少量线程 + 非阻塞 IO（NIO/事件循环/协程）承载大量并发，单机可承载数万/数十万并发，吞吐更高、资源占用更低。影响：同步模型在并发高时易成为压测工具瓶颈（需分布式）；异步模型吞吐高、单机能力强。选型时若目标并发高，优先异步 IO 工具，避免压测工具自身成为瓶颈。理解线程模型差异是压测工具选型与容量规划的关键。

同步线程模型并发受限，异步 IO 模型吞吐高。高并发压测需选异步工具避免工具自身瓶颈。

• 流量染色
• 影子库
• 容量评估

全链路压测（production testing）在生产环境对全链路做压测，工程实践：1) 流量染色：压测流量带标记（header/参数），通过中间件识别并路由到影子资源，不影响真实流量；2) 影子库/影子表：压测数据写入影子库（隔离的 DB/Redis），避免污染生产数据，通过染色标记路由；3) 容量评估：在全链路压测中观察各链路节点（网关、服务、DB、缓存）的 QPS、延迟、资源，定位瓶颈与最大容量，评估系统扩容需求；4) 隔离与安全：压测流量隔离、超时熔断、压测后清理。价值：全链路压测反映真实多服务依赖的容量，比单服务压测更准确。需完善的染色机制与影子资源治理。

全链路压测通过流量染色隔离压测流量、影子库隔离数据，评估真实容量。理解染色与影子机制是关键。

• 冒烟压测
• 性能回归门禁
• CI 集成

CI 中的轻量冒烟压测与性能回归门禁：1) 冒烟压测：在 CI 中跑少量、短时的压测（如 k6 冒烟测试，低并发、短时长），验证应用可正常响应、基本性能无严重退化，快速反馈；2) 性能回归门禁：用基准测试（JMH）或轻量压测设置性能阈值（如 p95 延迟 < 阈值、吞吐不低于基线 X%、错误率 < 阈值），作为质量门禁，超出则构建失败；3) 与基线对比：与历史/基准性能对比，检测回归（diff 基准）；4) 集成：CI 流水线中作为阶段，失败阻断合并/发布。注意：CI 环境资源有限，冒烟压测要轻量（避免掩盖真实环境差异），性能回归门禁结合基线对比，生产级性能用独立压测环境。价值是"每次变更自动检测性能回归"。

CI 冒烟压测快速反馈，性能回归门禁用基线对比阻断退化。理解轻量化与基线对比是关键。