北京云网站建设,徐州品牌网站建设,ps网上教程,深圳网站设计哪家好目标#xff1a;在不打穿下游的前提下#xff0c;验证入口链路的高并发承载能力#xff0c;并形成可复制的压测脚本。一、为什么要先压“入队链路”#xff1f;很多系统的重任务#xff08;报表、地图/视频处理、机器人调度等#xff09;都会走 “请求→入消息队列→异步…
目标在不打穿下游的前提下验证入口链路的高并发承载能力并形成可复制的压测脚本。
一、为什么要先压“入队链路”很多系统的重任务报表、地图/视频处理、机器人调度等都会走 “请求→入消息队列→异步消费” 的模式。
上线前必须回答三个问题峰值请求能不能稳稳接住网关限流能不能把洪峰挡在外面队列是否按预期累积不触发级联雪崩本实践选择 Dry-Run 禁用消费者 的“用法 A”请求只入队不真正执行耗时任务既能压出真实入口 QPS又不会把下游打穿观测面SkyWalking/RabbitMQ/JMeter一样齐全。
二、压测目标与环境目标100 QPS × 3 分钟可 50→100→200 QPS 梯度爬坡接口POST /external/gs/async/_mqSmoke创建“烟囱任务”仅入队网关策略必须带 X-Dry-Run:true否则 403命中限流返回 429观测SkyWalkingruoyi-gateway、ruoyi-robotRabbitMQ 控制台JMeter 报表结果判定JMeter Error%≈0SW SuccessRate≈100%、Apdex 高RabbitMQ Ready 累积三、脚本结构可直接照抄3.1 Test Plan 变量User Defined Variables
BASE_SCHEMEhttp
BASE_HOSTlocalhost
BASE_PORT8080 # 或直连 9300
SUBMIT_PATH/xxxxxx/_mqSmoke
POLL_PATH/xxxxxxx
AUTH_HEADER
POLL_INTERVAL_MS1200
MAX_POLLS20提示A 策略通常不启用轮询只压入队链路。
3.2 HTTP Header ManagerContent-Type: application/jsonX-Request-Id: ${__UUID()}Authorization: ${AUTH_HEADER}如需X-Dry-Run: true ← 关键3.3 SamplerSubmit Task (POST)Path${SUBMIT_PATH}Body
{xxxxx:dummy,taskName:mq-smoke}
3.4 线程组Thread Group调试Threads5, Ramp-up10s, Loop Count1正式Threads50, Ramp-up60s勾选 Specify Thread lifetime → Duration180s3.5 恒定吞吐定时器Constant Throughput TimerTarget throughput (samples per minute) 6000≈100 QPSCalculate Throughput based on this thread group only
小公式目标 QPS × 60 每分钟样本数。比如 100 QPS ⇒ 6000 samples/min。
3.6 断言与 429 处理Response AssertionResponse Code 允许 200 / 202 / 429JSR223 PostProcessor 将 429 记为成功
if (prev.getResponseCode() 429) { prev.setSuccessful(true)
}
3.7可选轮询逻辑非 Dry-Run 时用JSON Extractor变量xxxxJsonPathxxxxxxxWhile Controller 条件
${__groovy((vars.get(done)!true) ((vars.get(polls) as int ?: 0) (${MAX_POLLS} as int)))}
轮询定时器Constant Timer → ${POLL_INTERVAL_MS}JSR223 PostProcessor
def s (vars.get(status) ?: vars.get(state) ?: ).toString().toUpperCase()
def code (vars.get(code) ?: ).toString()
def doneVals [DONE,SUCCESS,FINISHED,COMPLETED,OK]
if (doneVals.contains(s) || code 200) { vars.put(done,true) }
int p (vars.get(polls) as int ?: 0) 1
vars.put(polls, String.valueOf(p))
四、执行步骤预热1 分钟 / 5 线程JMeter View Results Tree 绿灯SW“服务列表/端点负载”出现。正式压测100 QPS × 3 分钟打开 Aggregate Report同时观看SkywalkingRabbitMQ 队列 robot.tempTask.qReady 累积曲线。非 GUI 推荐更稳
jmeter -n -t async-submit-poll.jmx -l result.jtl -e -o html
五、观测与判读JMeter关注 #Samples / Average / P95 / P99 / Error% / Throughput。示例多轮实测Error%0P95≈6msP99≈9–10msThroughput≈41–100/sec视目标而定。SkyWalking关注 Service Loadcalls/min、Success Rate、Apdex、P95/P99。示例ruoyi-gateway Load ≈ 2300–2900/minSuccess 100%Apdex≈0.83–0.94ruoyi-robot Load ≈ 2800–4700/minSuccess 100%Apdex≈1.0。RabbitMQA 策略下消费者禁用Ready 持续累积是预期Unacked≈0。
六、SkyWalking“防自杀”设置很关键压测期间观测系统太“勤奋”也会被打爆建议Java Agentagent.config 增量
sample_n_per_3_secs10
trace.ignore_path/external/gs/async/_mqSmoke
采样降低到“每 3 秒 ~10 条”并忽略高频压测路径。 2.OAP Server 内存Windows 示例
set SW_OAP_OPTIONS-Xms512m -Xmx1024m -XX:UseG1GC
bin\oapService.bat stop
bin\oapService.bat start3.UI 时间范围 只看“今天”避免渲染大量历史数据变卡。七、常见问题与排错清单Q1另一台机器跑出来 Success 只有 50%Apdex 0.30.4
A一般是本机资源/网络/观测开销导致JMeter 用 GUI 跑 开很多监听器CPU 飙高网络丢包/代理/防火墙没有把 429 记为成功SW 采样太高/OAP 内存太小网关策略不一致是否强制 Dry-Run是否命中限流。Q2SW 过 2 分钟就“白屏/转圈”降采样见上忽略高频路径给 OAP 多点内存缩短 UI 时间窗口。Q3JMeter 吞吐达不到配置的 QPSThreads 不够、Ramp-up 太短、Timer 作用域不对脚本夹了多余“思考时间”机器顶不住CPU/内存/网络/磁盘。Q4网关 403确认头 X-Dry-Run: true未带头被路由策略拦截是对的。Q5换一台电脑为什么 SkyWalking 上看到的成功率、Apdex、负载和上一台不一样
现象同一套后端与脚本不同压测机跑出来的 SW 成功率/Apdex/Load 有明显差异甚至一台高、一台低。
根因分类 快速排查压测端JMeter差异GUI 监听器过多、开着 View Results Tree/GraphsCPU 抢占高 → 真实吞吐达不到配置值。机器性能/电源模式不同省电/节能模式、CPU 频率被限。Java/JMeter 版本/JVM 参数不同GC/HTTP 堆栈差异。脚本细节不一致线程数、Ramp-up、Constant Throughput Timer 的“作用域”不是 this thread group only或 429 未被标记为成功JMeter 与 SW 统计口径不一致。建议非 GUI 模式运行 jmeter -n ...只保留 Aggregate Report固定 Java 版本核对 .jmx 差异把 429 设为成功。网络路径差异一台走 公司代理/本机代理/VPN、一台直连DNS 解析落到不同网关实例丢包/抖动导致重传与超时。建议两机都 tracert/ping 网关禁用代理/VPN固定目标 IP同时抓一小段 tcpdump/Wireshark 看重传/RTT。SkyWalking 观测口径差异时间窗口不同另一台选了更大范围或不是“今天”筛选条件实例/端点不同。采样率不同另一台机器或另一环境的 sample_n_per_3_secs/sampleRate 不一致或者没有 trace.ignore_path导致 UI/存储压力大指标被稀释或 UI 卡顿。OAP 内存不足/存储后端压力大 → 指标迟到/掉点。建议两边统一时间范围Today 同步 NTP清空所有筛选统一 Agent 配置采样 忽略压测路径OAP 增内存例如 -Xms512m -Xmx1024m必要时只看压测时段 2–5 分钟窗口。网关/服务端策略差异限流/熔断/鉴权配置在不同实例不一致请求头如 X-Dry-Run:true / Authorization在一台机器未携带导致 403/429 比例变化。建议抓包或开启网关 access log 校验请求头对比实例配置将压测流量固定到同一实例临时关闭负载均衡或用权重/灰度。时钟偏差与统计口径压测机与 SW/OAP 时钟不同步导致“每分钟调用数Load”按窗口聚合时分桶不齐。建议所有机器启用 NTPSW UI 选择近实时小窗口例如最近 5 分钟。一键对齐清单两台压测机都做用 非 GUI 模式跑Aggregate Report 保存到文件检查 .jmx 完全一致线程/Timer 作用域/断言/429 处理固定 Java 版本关闭省电模式统一 Agent 配置sample_n_per_3_secs10、trace.ignore_path/external/gs/async/_mqSmokeOAP-Xms512m -Xmx1024m -XX:UseG1GCUI 只看“今天/最近 5 分钟”关闭代理/VPN固定网关实例或检查负载均衡所有节点开启 NTP 对时。
结论压测端供给能力 网络路径 观测采样/窗口 是造成 SW 指标差异的三大源头。把三者对齐后两台机器的曲线会非常接近。
八、可复用产物async-submit-poll.jmx线程组 恒定吞吐 Header POST 可选轮询/断言/JSR223网关路由与限流规则/external/gs/async/** 强制 X-Dry-Run:true 统一 429SW 配置片段sample_n_per_3_secs、trace.ignore_path、OAP JVM 参数
九、实战结论在“Dry-Run 禁消费”的保护模式下入口链路稳定撑住 100 QPS×3minJMeter Error%0P95/P99 低网关/业务 Success≈100%、Apdex 高RabbitMQ Ready 按预期累积无 Unacked 积压。
