面向全栈开发者的性能压测实战指南——claude-skills 中 monitoring-expert 的 k6、Artillery、Locust 与 JMeter 工具箱【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills性能压测是观测体系Observability中承上启下的一环它把指标、追踪、告警从被动观察变成主动验证。本文聚焦于 claude-skills 开源仓库中 monitoring-expert 技能所附的 性能测试参考文档系统讲解 k6 负载测试脚本、四类经典压测场景Load / Stress / Spike / Soak、Artillery、Locust、JMeter 五种工具的落地写法并给出可直接运行的自定义指标与真实用户旅程场景示例。读完本文你将能够独立编写带阈值门禁的压测脚本、按业务目标设计压测场景并把压测结论与 Prometheus 告警规则、容量规划衔接起来。该参考文档被两个技能同时引用monitoring-expert/SKILL.md 将其定位为负载测试、k6、Artillery、基准测试时的取用参考test-master/SKILL.md 也把它列为性能测试专业的必读资料。这意味着这套压测方法论既是监控专家进行容量验证的工具也是测试专家交付性能质量门禁的依据。一、从零开始基于 k6 的负载测试脚本k6 是本文档的主力工具它用 JavaScript 描述虚拟用户行为支持stages阶段式负载与thresholds阈值门禁两大核心机制。文档给出的完整脚本是压测脚本的标准骨架import http from k6/http; import { check, sleep } from k6; import { Rate } from k6/metrics; const errorRate new Rate(errors); export const options { stages: [ { duration: 2m, target: 100 }, // Ramp-up to 100 users { duration: 5m, target: 100 }, // Stay at 100 users { duration: 2m, target: 200 }, // Ramp-up to 200 users { duration: 5m, target: 200 }, // Stay at 200 users { duration: 2m, target: 0 }, // Ramp-down to 0 users ], thresholds: { http_req_duration: [p(95)500, p(99)1000], http_req_failed: [rate0.01], errors: [rate0.1], }, }; export default function () { const res http.get(https://api.example.com/products); check(res, { status is 200: (r) r.status 200, response time 500ms: (r) r.timings.duration 500, }) || errorRate.add(1); sleep(1); }拆解这个脚本可以看到它覆盖了压测脚本的全部要素stages阶段负载用{ duration, target }数组描述 VU虚拟用户数量的变化曲线。上面的示例采用2 分钟爬升到 100 → 保持 5 分钟 → 爬升到 200 → 保持 5 分钟 → 归零的双台阶曲线这是典型的先验证基线、再验证扩容策略。每个target指的是并发虚拟用户数而不是每秒请求数RPS两者通过sleep(1)建立关联——每个 VU 每秒发出一个请求。thresholds阈值门禁这是 k6 区别于普通压测脚本的关键能力。http_req_durationHTTP 请求时长要求p(95) 500ms、p(99) 1000mshttp_req_failed失败请求占比要求低于 1%自定义错误率指标errors要求低于 10%。压测结束后k6 会根据这些阈值判定测试通过/失败天然适合接入 CI/CD。check断言 自定义Rate指标check对单次响应做断言状态码、响应时间并通过|| errorRate.add(1)把断言失败累计到自定义的错误率指标上。这里体现了一个重要设计http_req_failed只统计传输层失败连接错误、5xx而业务层断言失败需要靠自定义Rate指标来兜底。在 monitoring-expert/SKILL.md 的快速上手示例中还有一个更精简的入门版脚本1m爬升 →5m保持 →1m归零阈值只保留p(95)500与rate0.01适合作为最小可运行模板。两相对照可以看出生产级压测脚本通常还需要加入多个负载台阶、p99 阈值与自定义业务指标。二、四类压测场景Load、Stress、Spike、Soak压测不是使劲打而是按目标区分测试类型。文档用 k6stages给出了四类场景的标准写法它们共享相同的语法差异全在负载曲线的形状上。2.1 Load Test负载测试验证正常容量// Gradual ramp-up to expected production load export const options { stages: [ { duration: 5m, target: 100 }, { duration: 30m, target: 100 }, { duration: 5m, target: 0 }, ], };缓慢爬升到预期的生产负载并长时间保持验证系统在正常峰值下能否满足 SLO。它是性能回归测试的标准形态通常在每次发版前运行。2.2 Stress Test压力测试找出崩溃点// Push beyond normal capacity to find breaking point export const options { stages: [ { duration: 2m, target: 100 }, { duration: 5m, target: 200 }, { duration: 5m, target: 300 }, { duration: 5m, target: 400 }, { duration: 2m, target: 0 }, ], };逐级加压直到系统出现错误率飙升、延迟恶化或不可用从而确定容量天花板。压力测试的产出不是通过/失败而是系统在多少负载下崩溃、以何种方式崩溃。2.3 Spike Test尖峰测试模拟突发流量// Sudden increase in load export const options { stages: [ { duration: 1m, target: 100 }, { duration: 30s, target: 1000 }, // Spike { duration: 3m, target: 100 }, { duration: 1m, target: 0 }, ], };关键在30s内从 100 猛拉到 1000模拟大促开场、秒杀、热点事件带来的瞬时流量。它重点考察的是自动扩容的响应速度、连接池的弹性以及系统崩溃后的恢复能力。2.4 Soak Test浸泡测试暴露内存泄漏// Extended duration at normal load export const options { stages: [ { duration: 5m, target: 100 }, { duration: 8h, target: 100 }, // Long duration { duration: 5m, target: 0 }, ], };在正常负载下运行长达 8 小时甚至更久专门用于暴露短时间压测发现不了的问题——内存泄漏、文件句柄泄漏、连接泄漏、GC 恶化。快速参考表给出的典型时长是 4–24 小时。需要特别指出的是文档把这四类测试放在 monitoring-expert 的技能域内说明它不只是测试工程师的打流工具更是监控专家验证容量模型、校准告警阈值的输入压测得到的 p95/p99 延迟与错误率正是 alerting-rules.md 中HighLatency、HighErrorRate告警阈值设置的现实依据。三、其余三款压测工具Artillery、Locust 与 JMeter3.1 Artillery.ioYAML 驱动的简洁场景Artillery 用 YAML 描述负载与场景上手成本最低适合简单场景快速验证。文档中的load-test.yml是完整的可运行示例# load-test.yml config: target: https://api.example.com phases: - duration: 60 arrivalRate: 10 name: Warm up - duration: 300 arrivalRate: 50 name: Sustained load processor: ./custom-functions.js variables: userId: - user1 - user2 scenarios: - name: Product browsing weight: 70 flow: - get: url: /products - think: 2 - get: url: /products/{{ $randomNumber(1, 100) }} - name: Checkout weight: 30 flow: - post: url: /cart json: productId: {{ $randomNumber(1, 100) }} - post: url: /checkout json: userId: {{ userId }}其中几个关键配置项值得注意phases按时间定义到达率arrivalRate单位每秒到达的用户数比 k6 的并发 VU 更贴近请求到达率模型。processor指定自定义 JS 函数文件用于处理模板变量或扩展逻辑。variables 模板变量userId定义了一组固定取值通过{{ userId }}注入请求体{{ $randomNumber(1, 100) }}则是内置随机函数模拟真实用户浏览不同商品页的行为。scenariosweight用权重模拟混合用户群——70% 的用户在浏览商品30% 的用户在走结算流程。think指令模拟用户思考停顿时间让流量更贴近真实。Artillery 与 k6 的定位差异可以用文档快速参考表的一句话概括Artillery 适合简单场景k6 适合API 测试与 CI/CD 集成。3.2 Locust用 Python 描述复杂场景Locust 的最大优势是用 Python 写压测因此天然可以复用项目的业务代码与数据工厂适合需要复杂计算、自定义负载分布的团队。文档示例from locust import HttpUser, task, between class WebsiteUser(HttpUser): wait_time between(1, 3) task(3) def view_products(self): self.client.get(/products) task(1) def view_product(self): product_id random.randint(1, 100) self.client.get(f/products/{product_id}) task(1) def create_order(self): self.client.post(/orders, json{ product_id: random.randint(1, 100), quantity: random.randint(1, 5) }) def on_start(self): # Login or setup self.client.post(/login, json{ username: test, password: test })task(n)装饰器n为权重3:1:1 表示产品列表、单品详情、下单三类操作的执行频率比。wait_time between(1, 3)控制用户操作间的等待时间区间秒模拟真实思考延迟。on_start每个虚拟用户首次启动时执行典型用途是登录并维持会话session保证后续请求携带认证态——这与 test-master 中带鉴权的 API 压测是同一思路。3.3 JMeterXML 线程组配置JMeter 以 GUI 著称配置文件.jmx本质上是 XML。文档给出的线程组最小配置如下!-- Basic HTTP Request -- ThreadGroup stringProp nameThreadGroup.num_threads100/stringProp stringProp nameThreadGroup.ramp_time60/stringProp stringProp nameThreadGroup.duration300/stringProp boolProp nameThreadGroup.schedulertrue/boolProp /ThreadGroup四个属性分别对应线程数 100、爬升时间 60 秒、运行时长 300 秒、启用调度器schedulertrue后duration才生效。当被测系统是遗留系统、或团队已习惯 JMeter GUI 生态时它仍是可靠选择文档快速参考表将其定位为Legacy systems场景下的工具。四、自定义性能指标Counter、Trend 与 Gauge内置指标只能回答延迟和错误率业务级指标如结算耗时、购物车大小、下单量需要自定义。文档展示了 k6 的三种自定义指标类型// k6 custom metrics import { Counter, Trend, Gauge } from k6/metrics; const checkoutDuration new Trend(checkout_duration); const cartSize new Gauge(cart_size); const orderCounter new Counter(orders_created); export default function () { const startTime Date.now(); const res http.post(https://api.example.com/checkout, payload); checkoutDuration.add(Date.now() - startTime); orderCounter.add(1); cartSize.add(payload.items.length); }Trend趋势记录一系列数值输出均值、分位数等统计量。checkout_duration用Date.now()差值手动计算结算全流程耗时——注意它包含了请求后可能的处理时间而不仅仅是 HTTP 往返时长。Counter计数器单调累加orders_created用来统计整个压测期间创建订单的总数与速率。Gauge仪表保留最近一次记录的瞬时值cart_size记录每笔订单的商品数适合监控当前值而非累计值。自定义指标与thresholds联动是常见用法thresholds: { checkout_duration: [p(95)1000] }即可把结算流程 p95 必须小于 1 秒固化为门禁。这与 prometheus-metrics.md 中 Counter / Histogram / Summary 的分类思想一脉相承——压测脚本中的Trend对应监控侧的Histogram直方图按桶分布Gauge一一对应Counter也同名同义理解了这一层映射压测指标与生产监控指标就能无缝对齐。五、测试场景设计多执行器模拟混合用户群真实系统同时服务浏览器用户和API 客户端它们的流量模型完全不同。k6 的scenarios场景编排机制允许在同一测试中混合多种执行器executor。文档给出了经典的双场景示例// Realistic user journey import { scenario } from k6/execution; export const options { scenarios: { browser_users: { executor: ramping-vus, startVUs: 0, stages: [ { duration: 5m, target: 100 }, { duration: 10m, target: 100 }, ], gracefulRampDown: 30s, }, api_users: { executor: constant-arrival-rate, rate: 50, timeUnit: 1s, duration: 15m, preAllocatedVUs: 100, }, }, };两个执行器的语义差异决定了它们各自的适用场景ramping-vus爬升虚拟用户以并发用户数为粒度配合stages控制曲线gracefulRampDown: 30s保证收尾阶段已开始的请求能优雅完成。适合模拟浏览器用户这类长会话、低频率的流量。constant-arrival-rate恒定到达率以每秒迭代次数为粒度rate: 50, timeUnit: 1s即每秒发起 50 次迭代preAllocatedVUs: 100预分配足够 VU 池。适合模拟 API 客户端这类短请求、高频次的流量。文档还给出了一个完整的真实用户旅程实现——用随机数模拟用户行为概率export default function () { // Homepage http.get(https://example.com/); sleep(Math.random() * 3); // Search http.get(https://example.com/search?qlaptop); sleep(Math.random() * 5); // Product page http.get(https://example.com/products/123); sleep(Math.random() * 10); // Add to cart (30% conversion) if (Math.random() 0.3) { http.post(https://example.com/cart, { productId: 123 }); } }这套写法把随机思考时间 条件转化概率组合起来sleep(Math.random() * 3)模拟 0–3 秒的随机停留if (Math.random() 0.3)把 30% 的流量引向加购操作。相比固定脚本这种概率化行为更能还原真实用户漏斗压测结果也更接近生产。六、压测指标与结果解读速查文档最后用三张速查表收束全文它们也是压测报告和 SLO 定义时的直接参考。6.1 测试类型选择Test TypePurposeDurationLoadNormal capacity30m - 2hStressFind limits1h - 4hSpikeSudden traffic15m - 30mSoakMemory leaks4h - 24h选择逻辑很直接日常回归用 Load容量摸底用 Stress大促/热点预案用 Spike发布前做长稳验证用 Soak。6.2 工具选型ToolLanguageBest Fork6JavaScriptAPI testing, CI/CDArtilleryYAML/JSSimple scenariosLocustPythonComplex scenariosJMeterGUI/XMLLegacy systems结合 test-master 中性能测试用 k6 或 Artillery的表述可以看出本仓库的技能体系把 k6 视为 CI 集成的首选Artillery 作为轻量补充而 Locust 与 JMeter 则面向有语言偏好或遗留系统约束的团队。6.3 目标指标参考值MetricTargetp95 latency 500msp99 latency 1sError rate 1%RPS10x normal这些数值需要与业务场景配合使用而不是一刀切。在 capacity-planning.md 的性能预算Performance Budgets一节中预算对象被进一步细化——Web 页面关注ttfb200ms、fcp1000ms、lcp2500msAPI 关注apiP50100ms、apiP95500ms、apiP991000ms基础设施则关注 CPU 利用率70%与内存利用率80%。RPS 达到日常 10 倍这一条也与压力测试的目标互相印证——它定义的是压测要打到的量级而不是生产要承受的量级。七、把压测融入可观测闭环压测的价值只有在与生产监控打通时才完整。在 claude-skills 的技能体系中monitoring-expert/SKILL.md 定义的 Core WorkflowAssess → Instrument → Collect → Visualize → Alert中性能压测扮演着验证者的角色从 SLO 反推压测阈值先在 alerting-rules.md 中定义目标如 p95 延迟 1s 触发 warning、错误率 5% 触发 critical再把同样的数字写进 k6 的thresholds保证压测门禁与生产告警口径一致。用压测结果校准告警参数压测中记录的真实延迟分布、错误率基线是避免 SKILL.md 中 Alert on every error (alert fatigue) 误报的最佳数据来源。衔接容量规划压测测出的单实例 RPS 容量直接输入 capacity-planning.md 的calculateInstances(targetRPS, instanceCapacity)等估算公式为扩容决策与 HPA 阈值提供依据。回归与 CI 集成把 k6 脚本放入流水线p(95)500之类的阈值不达标即构建失败实现性能回归的自动化门禁——这也是文档将 k6 定位为 API testing, CI/CD 的原因。需要留意的是参考文档中的示例 URL 与账号如api.example.com、user1/user2均为占位符落地时需替换为真实环境参数压测目标环境也建议先在预发环境验证脚本正确性再对生产施压。结语性能压测的本质是用可量化的负载曲线提前回答三个问题系统能承受多少、在哪儿崩溃、崩溃后能否恢复。claude-skills 中 monitoring-expert 的这份参考文档给出了从单脚本到场景编排、从单工具到多工具选型、从指标采集到结果判读的完整答案。你可以从文档中的 k6 完整示例开始先跑通一个带阈值门禁的负载测试再按本文第四节为业务定制 Counter/Trend/Gauge 指标最后用scenarios混合浏览器与 API 用户流量把压测结果沉淀为生产告警与容量规划的输入形成真正闭环的可观测实践。如需进一步深挖建议继续阅读同技能下的 alerting-rules.md告警规则设计、capacity-planning.md容量预估与扩容、application-profiling.mdCPU/内存剖析或参考 test-master 中带鉴权 API 压测的完整 k6 写法。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考