如何使用JMeter或Locust对Jenkins主从节点开展负载测试

适用场景：30个注册Agent、1000个存量Job的Jenkins集群，同时验证Master调度/API性能、Agent任务承载能力 #

一、测试前置准备 #

• 基线数据摸排：提前统计集群日常运行基线，包括Master节点CPU、内存、磁盘IO、JVM堆使用率、构建队列长度、Web请求平均延迟；30个Agent的日常空闲率、单Agent并发构建上限；1000个Job的类型占比（流水线/自由风格）、平均单Job执行时长、日常峰值并发构建数、SCM轮询频率，所有压测结果对标基线才有参考价值。注意压测环境需和生产配置完全对齐，若必须在生产压测，选业务低峰期操作，提前做全量备份，配置压测自动熔断阈值，避免影响正常业务
• 权限配置：在Jenkins侧创建压测专用账号，授予全局读、Job构建、Agent连接操作权限，生成对应API Token，避免压测过程中触发账号限流、权限拦截导致的结果失真。
• 压测工具适配：
  • Master节点的Web/API层、队列调度能力压测选JMeter：自带HTTP请求采样器，支持参数化与指标聚合，若单台压测机发压能力不足，部署JMeter分布式集群多节点发压，避免压测机自身成为瓶颈
  • Agent节点任务执行、Master-Agent通信链路压测选Locust：Python脚本灵活度高，可模拟真实构建的资源消耗、文件传输、命令执行逻辑，分布式部署成本低
• 监控埋点：提前搭好秒级粒度监控，Master侧采集JVM GC指标、Jenkins内置/metrics/*接口暴露的队列等待数、调度线程池使用率、Agent在线数、请求错误率；Agent侧采集CPU、内存、磁盘IO、网络带宽、Agent进程资源占用；所有监控指标和压测流量时间点对齐打标，方便后续定位瓶颈。

二、测试场景与脚本开发 #

1. Master压测场景（JMeter实现） #

• 日常操作模拟：按生产真实请求权重配置采样器，60%流量为查询类请求（查看Job列表、拉取构建历史、读取构建日志、查询构建状态），30%为操作类请求（触发Job构建、终止构建），10%为配置类请求（修改Job配置、创建凭据），还原日常用户操作的负载模型
• 峰值调度模拟：配置短时间内批量触发数百个Job的场景，验证Master队列调度逻辑，排查是否存在队列阻塞、调度超时、OOM等问题
• SCM轮询洪峰模拟：模拟1000个Job同时到达SCM轮询周期，并发判断代码变更、触发构建的场景——这是Jenkins Master最容易出现卡顿的高频场景
• 脚本校验：所有请求携带压测账号API Token做认证，参数化配置Job名称、构建ID等变量，添加响应断言（比如触发构建成功返回201状态码、队列查询返回正确排队位置），避免把错误响应当成正常流量统计。

2. Agent与链路压测场景（Locust实现） #

• 常规并发构建模拟：从单Agent跑2个并发构建开始，逐步提升并发数到5、8、10个，验证单Agent资源阈值，同时验证Master向高负载Agent调度任务时的排队逻辑是否正常
• 大文件传输模拟：模拟构建过程中Master向Agent分发大体积构建包、Agent向Master回传大体积构建产物的场景，验证网络带宽占满时是否会出现构建超时、连接断连问题
• 异常容错模拟：压测过程中随机重启部分Agent进程、临时中断Agent和Master的网络连接，验证高负载下Master的重连、任务重试/转移逻辑是否正常，是否存在任务丢失、重复调度问题
• 脚本校验：不要只跑空命令的测试构建，用stress、dd等命令模拟真实Job的CPU、内存、磁盘IO消耗，按真实构建的日志输出速度打印日志，否则测出来的Agent承载上限完全没有参考价值。

三、压测执行流程 #

• 基准测试阶段：先单独压测Master，不启动Agent上的真实构建任务，只压API和调度逻辑，拿到Master单组件性能基线；再单独压测单个Agent，拿到单Agent最大并发构建数、资源阈值，作为全链路压测的参考基准
• 梯度增压阶段：从日常平均负载的30%开始发压，每10分钟提升20%负载，直到负载达到日常峰值的200%，每个负载梯度稳定运行5分钟以上再记录指标，不要一下子打满流量把集群打挂，看不到完整的瓶颈变化过程
• 故障注入阶段：把集群负载稳定在日常峰值的120%，依次注入故障：重启1/3数量的Agent、重启Master上的Jenkins进程、断开Master网络10秒，验证集群容错能力，排查是否存在数据损坏、任务大面积失败的问题
• 极限压测阶段：持续提升压测流量，直到集群出现明确性能拐点：Master API响应延迟超过3s、构建平均排队时长超过10分钟、Agent CPU/内存使用率持续超过95%、构建错误率超过1%，记录此时的负载值作为集群最大承载上限。

四、瓶颈定位与优化参考 #

• 若Master侧API响应慢：优先排查JVM堆内存是否不足、是否频繁触发Full GC，再检查Jenkins Web线程池配置是否过小，是否存在冗余插件拖慢接口响应
• 若构建队列持续堆积：排查Jenkins调度线程数配置是否合理、Agent在线状态是否正常，是否存在卡死的构建任务长期占用Agent名额不释放
• 若Agent侧构建频繁超时：排查Agent磁盘IO是否打满、网络带宽是否不足，或者Agent进程JVM内存配置过低导致频繁GC
• 所有配置调整完成后，重新跑全量压测场景验证优化效果，直到集群承载能力满足业务峰值冗余要求。

内容的提问来源于stack exchange，提问作者devops_jy