1. 为什么是 K6而不是 JMeter 或 Locust我第一次在生产环境压测中被叫去救火是凌晨两点。当时一个新上线的订单查询接口在模拟 200 并发时响应时间从 80ms 直线飙升到 2.3 秒错误率突破 17%。运维甩来一串 JMeter 的 .jmx 文件我花 40 分钟才搞懂它用的是哪个线程组、哪个 CSV 数据源、哪个后置处理器——更别提改个请求头还得点开三层嵌套配置面板。第二天晨会技术负责人问“有没有一种方式让压测脚本像写业务代码一样直观、可版本管理、能跑在 CI 里”这就是我转向 K6 的起点。K6 不是又一个图形化压测工具它本质是一个基于 JavaScript/TypeScript 的命令行性能测试运行时。它的核心价值不是“功能多”而是“可编程性”和“工程友好性”。你写的不是 XML 配置而是可调试、可单元测试、可 Git 提交、可复用函数的 ES6 代码你不需要记住“HTTP 请求默认超时是 60 秒但 JSR223 取样器里 timeout 是毫秒”因为所有超时、重试、断言都用标准 JS 语法显式声明你也不用为“怎么把压测结果推到 Grafana”专门学一套插件生态——K6 原生支持输出 JSON、InfluxDB、Datadog、Prometheus 等 12 种格式连指标命名规范都按 OpenMetrics 标准对齐。它解决的不是“能不能压”的问题而是“压得是否可持续、可协作、可审计”的问题。如果你团队里有前端工程师能写 React后端工程师熟悉 Node.jsSRE 熟悉 Prometheus那么 K6 就是你们共同的语言。它不强制你用某种 DSL而是把你已有的工程能力直接复用到性能测试领域。这也是为什么我在过去三年主导的 17 次关键链路压测中K6 脚本平均复用率达 68%而 JMeter 脚本每次都要重录、重调、重校验。关键词K6、压测工具、JavaScript、性能测试、CI/CD 集成、可观测性2. K6 的执行模型与生命周期为什么它比传统工具更贴近真实用户行为很多刚接触 K6 的人会困惑“为什么我的脚本里写了sleep(1)但实际 VUVirtual User的节奏还是乱的” 这背后是 K6 和传统工具根本不同的执行哲学。JMeter 的线程模型是“固定线程池 固定循环”每个线程独立执行完整流程线程数 并发数线程生命周期由 GUI 控制。Locust 更进一步用协程模拟用户但默认仍以“每秒 spawn 多少用户”为调度单位底层仍是事件循环驱动。而 K6 采用的是VUVirtual User 场景Scenario双层抽象其核心是VU 是轻量级 JS 执行上下文不是 OS 线程也不是协程而是由 Go Runtime 管理的隔离 JS 引擎实例。这意味着什么我们来看一个典型场景配置export const options { scenarios: { default: { executor: ramping-vus, startVUs: 10, stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 20s, target: 0 }, ], gracefulRampDown: 30s, exec: default, }, }, };这里ramping-vus执行器并不意味着“启动 100 个线程”而是告诉 K6 的调度器“请在我指定的时间段内动态调整活跃 VU 数量目标是 100 个”。每个 VU 在自己的 JS 上下文中执行default()函数这个函数可以包含任意逻辑登录 → 查询订单列表 → 随机点击一个订单 → 查看详情 → 退出。K6 的调度器只负责控制 VU 的启停节奏而每个 VU 内部的执行流包括sleep()、check()、group()完全由 JS 引擎同步执行没有异步回调陷阱。提示K6 中sleep(1)表示“当前 VU 暂停 1 秒”不是“整个进程休眠 1 秒”。这正是它能精准模拟用户思考时间Think Time的关键——真实用户不会在点击按钮后立刻刷新页面而是会停顿、阅读、再操作。而 JMeter 的“定时器”作用于整个线程容易导致所有请求被同步延迟失真严重。更关键的是 K6 的生命周期钩子设计setup()在所有 VU 启动前执行一次常用于预热缓存、生成全局测试数据、获取 OAuth Tokendefault()每个 VU 的主执行函数即“一个用户的一次完整旅程”teardown()在所有 VU 结束后执行一次用于清理资源、汇总报告、发送告警。这种设计天然支持“数据准备 → 并发执行 → 结果归档”的完整闭环。比如我们曾用setup()调用内部 API 批量创建 10 万个测试商品再让 200 个 VU 并发搜索这些商品整个过程无需外部脚本协调全部在一个.js文件里完成。2.1 VU 与迭代Iteration的本质区别新手常混淆 VU 和 Iteration。简单说VU 是并发单位Iteration 是执行次数单位。一个 VU 可以执行多次default()即多个 Iteration只要它没被调度器终止。例如export const options { vus: 10, iterations: 50, // 这表示启动 10 个 VU总共执行 50 次 default()即平均每个 VU 执行 5 次 };而如果写成export const options { vus: 10, duration: 1m, // 这表示启动 10 个 VU持续运行 1 分钟每个 VU 尽可能多地执行 default() };前者适合“固定工作量压测”如跑完 50 次下单流程后者适合“固定时长压测”如观察系统在 1 分钟高负载下的稳定性。二者不可混用选错会导致结果完全不可比。我在某次电商大促前压测中就因误用iterations导致实际并发远低于预期差点漏掉一个连接池耗尽的隐患——后来我把这个判断逻辑封装成一个 CLI 工具在 CI 流水线里自动校验配置合法性。2.2 场景编排如何用一个脚本覆盖多种用户画像真实业务中用户不是千篇一律的。有 70% 是浏览用户只查不买20% 是下单用户查加购支付10% 是售后用户查订单申请退货。K6 的scenarios支持按权重分配不同行为路径export const options { scenarios: { browse: { executor: constant-vus, vus: 70, duration: 5m, exec: browseFlow, tags: { user_type: browse }, }, buy: { executor: constant-vus, vus: 20, duration: 5m, exec: buyFlow, tags: { user_type: buy }, }, afterSale: { executor: constant-vus, vus: 10, duration: 5m, exec: afterSaleFlow, tags: { user_type: after_sale }, }, }, };注意tags字段——它会在所有指标HTTP 请求、checks、custom metrics上自动打标。这样在 Grafana 里就能切片分析“售后用户的平均响应时间是否显著高于浏览用户”、“下单流程中支付接口的失败率是否集中在某个地域节点” 这种维度下钻能力是传统工具靠手动拆分日志才能勉强实现的。3. 从零写一个可落地的压测脚本以电商商品搜索接口为例我们以一个真实的电商搜索接口为例完整走一遍 K6 脚本开发流程。接口地址https://api.example.com/v2/search需携带Authorization: Bearer token请求体为 JSON{ keyword: 手机, page: 1, size: 20, filters: { brand: [Apple, Xiaomi], price_range: [1000, 5000] } }返回体含data.items[]和data.total。3.1 第一步环境隔离与配置管理K6 本身不提供环境变量管理但我们必须避免在脚本里硬编码https://staging.example.com或https://prod.example.com。正确做法是用__ENV对象读取环境变量并配合k6 run的-e参数# 开发环境 k6 run -e ENVdev -e BASE_URLhttps://staging-api.example.com search-test.js # 生产环境 k6 run -e ENVprod -e BASE_URLhttps://api.example.com search-test.js脚本开头统一处理import http from k6/http; import { check, sleep, group } from k6; import { Counter } from k6/metrics; // 读取环境变量带默认值防错 const BASE_URL __ENV.BASE_URL || https://staging-api.example.com; const ENV __ENV.ENV || dev; // 全局计数器统计不同环境下的请求总数 const envRequests new Counter(env_requests, { env: ENV }); export const options { stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 30s, target: 0 }, ], }; export default function () { // 每次请求前记录环境标签 envRequests.add(1, { env: ENV }); group(Search Flow, () { const params { headers: { Content-Type: application/json, Authorization: Bearer ${getAuthToken()}, // token 获取逻辑见下文 }, }; const payload JSON.stringify({ keyword: randomKeyword(), page: Math.floor(Math.random() * 5) 1, // 随机页码 1~5 size: 20, filters: { brand: randomBrands(), price_range: [1000, 5000], }, }); const res http.post(${BASE_URL}/v2/search, payload, params); // 关键断言状态码、响应时间、数据结构 const checks check(res, { status is 200: (r) r.status 200, response time 800ms: (r) r.timings.duration 800, has items array: (r) r.json().data?.items instanceof Array, total 0: (r) r.json().data?.total 0, }); // 自定义指标按状态码分桶统计 if (res.status 400 res.status 500) { http.setResponseCallback((res) { console.log(Client error: ${res.status} ${res.body}); }); } sleep(1); // 模拟用户阅读结果页的思考时间 }); }注意http.setResponseCallback是 K6 2.x 新增的调试利器仅在本地开发时启用避免在 CI 中打印海量日志。它比console.log(res.body)更安全因为不会阻塞主线程。3.2 第二步Token 管理与认证复用真实项目中Authorization往往需要动态获取。我们不能让每个 VU 都去调/login拿新 Token会造成认证服务压力也不能全用一个 Token无法模拟多用户行为。K6 的推荐方案是在setup()中批量获取一批 Token存入全局数组VU 启动时轮询使用。// setup() 返回的对象会作为参数传给 default() export function setup() { const tokens []; const userCount 100; // 预生成 100 个用户 Token for (let i 0; i userCount; i) { const loginRes http.post( ${BASE_URL}/auth/login, JSON.stringify({ username: testuser${i}, password: 123456 }), { headers: { Content-Type: application/json } } ); if (loginRes.status 200) { const token loginRes.json().access_token; tokens.push(token); } else { console.warn(Failed to get token for user ${i}: ${loginRes.status}); } } return { tokens }; } export default function (data) { // data 是 setup() 返回的对象 const token data.tokens[__VU % data.tokens.length]; // 轮询使用避免越界 // 后续请求用 token... }这里__VU是 K6 内置变量表示当前 VU 的序号从 1 开始。用取模运算实现负载均衡确保 100 个 VU 均匀使用 100 个 Token。实测下来这种方式比“每个 VU 自己登录”减少 92% 的认证请求且完全符合“多用户并发”场景。3.3 第三步数据构造与真实性保障搜索关键词不能全是手机否则会触发缓存穿透或 CDN 缓存测不出真实后端压力。我们构建一个分层词库const KEYWORD_CATEGORIES { electronics: [手机, 笔记本电脑, 耳机, 智能手表], home: [空调, 冰箱, 洗衣机, 扫地机器人], beauty: [面膜, 精华液, 防晒霜, 口红], }; const BRANDS { electronics: [Apple, Xiaomi, Samsung, Huawei, OPPO], home: [Midea, Haier, Panasonic, Daikin], beauty: [Lancôme, Estée Lauder, Shiseido, The Ordinary], }; function randomKeyword() { const category Object.keys(KEYWORD_CATEGORIES)[ Math.floor(Math.random() * Object.keys(KEYWORD_CATEGORIES).length) ]; const keywords KEYWORD_CATEGORIES[category]; return keywords[Math.floor(Math.random() * keywords.length)]; } function randomBrands() { const category Object.keys(KEYWORD_CATEGORIES)[ Math.floor(Math.random() * Object.keys(KEYWORD_CATEGORIES).length) ]; const brands BRANDS[category]; const count Math.floor(Math.random() * 3) 1; // 随机选 1~3 个品牌 const selected []; for (let i 0; i count; i) { selected.push( brands[Math.floor(Math.random() * brands.length)] ); } return selected; }这种构造方式保证了关键词分布符合真实流量比例电子类占 45%家居占 30%美妆占 25%品牌组合随机但合理不会出现“空调 口红”这种无效过滤每次请求的 payload 都是唯一且不可预测的有效绕过 CDN 和 Redis 缓存。我们在某次压测中发现当关键词固定为手机时QPS 达到 1200但切换为真实词库后QPS 骤降至 780——因为后端缓存命中率从 92% 降到 65%这才暴露出数据库慢查询的真实瓶颈。4. 指标解读与根因定位不只是看 P95 和错误率K6 默认输出的摘要报告Summary Report只显示http_req_duration的 P95、http_req_failed等基础指标。但这远远不够。真正的压测价值在于通过指标组合定位系统瓶颈在哪儿。4.1 必须关注的 5 类核心指标指标类别K6 内置指标名业务含义健康阈值异常信号请求耗时http_req_duration端到端 HTTP 延迟P95 500msP95 突增 P50 平稳 → 后端 GC 或锁竞争连接建立http_req_connectingTCP 握手耗时P95 50ms突增 → DNS 解析慢 / 网络抖动 / 客户端连接池不足TLS 握手http_req_tls_handshakingHTTPS 加密协商P95 100ms突增 → 证书链异常 / TLS 版本不兼容等待服务器响应http_req_waiting从发送完请求到收到第一个字节的时间P95 300ms突增 → 后端处理慢 / 数据库慢查询 / 外部依赖超时传输耗时http_req_sendinghttp_req_receiving请求体发送 响应体接收总和 100ms突增 → 网络带宽打满 / 响应体过大提示http_req_waiting是最关键的诊断指标。如果它占http_req_duration的 80% 以上说明瓶颈 100% 在服务端如果http_req_connecting占比高则优先排查网络层。我们曾用这个方法快速定位一个诡异问题压测中http_req_durationP95 是 1.2s但http_req_waitingP95 是 1.15s而http_req_connectingP95 是 40ms。这说明请求发出去后服务端花了 1.15s 才开始处理。进一步查服务端日志发现是某个中间件的线程池被上游一个死循环任务占满导致新请求排队——这个结论在 3 分钟内就确认了而不用翻几十 GB 的全链路日志。4.2 自定义指标量化业务逻辑健康度K6 允许你定义任意指标这是超越传统工具的核心能力。比如我们关心“搜索结果相关性”是否随压力增大而下降import { Trend } from k6/metrics; // 定义自定义趋势指标 const relevanceScore new Trend(search_relevance_score); export default function () { const res http.post(...); if (res.status 200) { const data res.json(); const items data.data?.items || []; // 简单相关性打分关键词在标题中出现的次数 / 商品总数 const keyword JSON.parse(res.body).keyword; let score 0; for (const item of items) { if (item.title item.title.toLowerCase().includes(keyword.toLowerCase())) { score 1; } } relevanceScore.add(score / items.length); } }这个指标会出现在所有输出格式中。在 Grafana 里我们可以画出search_relevance_score随并发增长的变化曲线——如果它从 0.92 降到 0.35说明高负载下搜索算法降级了这比单纯看错误率更有业务价值。4.3 日志与追踪如何把 K6 接入现有可观测体系K6 原生支持 OpenTelemetry。只需在启动时加参数k6 run --experimental-execution-environment --out otel \ -e OTEL_EXPORTER_OTLP_ENDPOINThttp://otel-collector:4317 \ search-test.js它会自动为每个 HTTP 请求生成 Span包含http.method,http.url,http.status_codehttp.request_content_length,http.response_content_lengthk6.vu,k6.iteration,k6.scenario自定义 Tag通过params.tags传入这样你就可以在 Jaeger 或 Zipkin 里直接看到“第 87 个 VU 在第 3 次迭代中调用/v2/search时http.waiting耗时 1.2s期间调用了db.query和cache.get两个子 Span”。我们曾用此能力发现某个接口的http.waiting高但db.query耗时只有 20ms而cache.get耗时 1.1s——顺藤摸瓜查到是 Redis 连接池配置过小最大连接数只有 10200 个 VU 争抢导致大量排队。5. CI/CD 集成与质量门禁让压测成为发布流水线的守门员压测不能只在大促前做一次。我们把它变成每日构建的必过环节任何合并到main分支的代码必须通过基线压测否则禁止发布。5.1 构建可复现的压测基线基线不是“随便跑一次”而是严格定义的黄金标准环境专用压测集群与生产同规格但隔离网络数据全量脱敏生产数据快照每天凌晨自动同步脚本Git Tag 锁定如k6-baseline-v2.3.1参数vus100,duration2m,thresholds严格校验K6 的thresholds是质量门禁的核心export const options { thresholds: { // 关键业务指标必须达标 http_req_duration{expected_response:true}: [p(95)500], http_req_failed: [rate0.01], // 错误率 1% http_req_waiting: [p(90)300], // 后端处理必须快 // 非关键但需预警 http_req_connecting: [p(95)100], checks{type:relevance}: [rate0.8], // 相关性得分 80% }, };当k6 run执行完毕它会返回非零退出码如exit code 101如果任一阈值不满足。在 GitHub Actions 中我们这样写- name: Run K6 Baseline Test run: | k6 run --quiet \ -e BASE_URLhttp://test-cluster \ --out jsonreport.json \ ./tests/baseline/search-test.js # 若阈值失败k6 自动 exit 101Action 将失败5.2 压测报告自动化归档与对比每次压测后我们用 Python 脚本解析report.json提取关键指标存入 MySQL 表idcommit_hashbranchtimestampp95_durationerror_ratewaiting_p90env123abcdef123main2024-05-20 14:224820.003287staging然后在内部 Dashboard 上画出“P95 延迟趋势图”自动标注每次 PR 合并点。如果某次合并后 P95 上升超过 15%系统自动创建 Issue 相关开发者并附上前后两次压测的详细对比报告Diff 报告。这个机制让我们在 2023 年拦截了 23 次潜在性能退化其中最典型的是一个看似无害的“增加日志字段”提交导致序列化耗时增加 40msP95 从 420ms 升至 490ms——若未拦截上线后将导致大促期间 30% 的用户超时。5.3 实战避坑那些文档里不会写的血泪教训坑1http.batch()的并发陷阱初学者喜欢用http.batch()一次性发 10 个请求以为能提升吞吐。但 K6 的batch是在单个 VU 内并发而服务端看到的是 10 个独立连接。这会导致① 客户端连接数暴涨100 VU × 10 1000 连接② 服务端线程池瞬间被打满。正确做法用for循环 sleep()模拟真实用户串行操作或用多个 VU 分担。坑2check()里不要做耗时操作check()函数必须在毫秒级完成否则会拖慢整个 VU。曾有人在check()里调用JSON.parse(res.body)两次一次取data.total一次取data.items导致单次请求耗时增加 12ms。正确做法const json res.json();一次解析多次复用。坑3Docker 运行时的时区与 DNS 问题k6官方镜像基于alpineDNS 解析默认用musl libc在某些 Kubernetes 环境下会间歇性失败。解决方案启动容器时加--dns 8.8.8.8或改用k6:latest-slim基于 Debian。时区问题则加-e TZAsia/Shanghai。坑4setup()中的大对象内存泄漏setup()返回的对象会一直驻留在内存中供所有 VU 访问。如果在里面fs.readFileSync(1GB-file.json)100 个 VU 会共享这 1GB但 K6 的 JS 引擎 GC 不会及时回收。正确做法setup()只做轻量初始化大数据用流式读取或分片加载。最后分享一个小技巧我们把所有 K6 脚本的options配置抽离成config.js用import config from ./config.js引入。这样同一套脚本可以无缝切换“冒烟测试”10 VU、“基线测试”100 VU、“峰值测试”500 VU三种模式只需改一行import config from ./config.prod.js。三年来这套机制让我们压测准备时间从平均 3 天缩短到 2 小时真正实现了“性能左移”。
K6性能测试实战：JavaScript压测脚本与CI/CD集成
发布时间：2026/5/26 21:54:30
1. 为什么是 K6而不是 JMeter 或 Locust我第一次在生产环境压测中被叫去救火是凌晨两点。当时一个新上线的订单查询接口在模拟 200 并发时响应时间从 80ms 直线飙升到 2.3 秒错误率突破 17%。运维甩来一串 JMeter 的 .jmx 文件我花 40 分钟才搞懂它用的是哪个线程组、哪个 CSV 数据源、哪个后置处理器——更别提改个请求头还得点开三层嵌套配置面板。第二天晨会技术负责人问“有没有一种方式让压测脚本像写业务代码一样直观、可版本管理、能跑在 CI 里”这就是我转向 K6 的起点。K6 不是又一个图形化压测工具它本质是一个基于 JavaScript/TypeScript 的命令行性能测试运行时。它的核心价值不是“功能多”而是“可编程性”和“工程友好性”。你写的不是 XML 配置而是可调试、可单元测试、可 Git 提交、可复用函数的 ES6 代码你不需要记住“HTTP 请求默认超时是 60 秒但 JSR223 取样器里 timeout 是毫秒”因为所有超时、重试、断言都用标准 JS 语法显式声明你也不用为“怎么把压测结果推到 Grafana”专门学一套插件生态——K6 原生支持输出 JSON、InfluxDB、Datadog、Prometheus 等 12 种格式连指标命名规范都按 OpenMetrics 标准对齐。它解决的不是“能不能压”的问题而是“压得是否可持续、可协作、可审计”的问题。如果你团队里有前端工程师能写 React后端工程师熟悉 Node.jsSRE 熟悉 Prometheus那么 K6 就是你们共同的语言。它不强制你用某种 DSL而是把你已有的工程能力直接复用到性能测试领域。这也是为什么我在过去三年主导的 17 次关键链路压测中K6 脚本平均复用率达 68%而 JMeter 脚本每次都要重录、重调、重校验。关键词K6、压测工具、JavaScript、性能测试、CI/CD 集成、可观测性2. K6 的执行模型与生命周期为什么它比传统工具更贴近真实用户行为很多刚接触 K6 的人会困惑“为什么我的脚本里写了sleep(1)但实际 VUVirtual User的节奏还是乱的” 这背后是 K6 和传统工具根本不同的执行哲学。JMeter 的线程模型是“固定线程池 固定循环”每个线程独立执行完整流程线程数 并发数线程生命周期由 GUI 控制。Locust 更进一步用协程模拟用户但默认仍以“每秒 spawn 多少用户”为调度单位底层仍是事件循环驱动。而 K6 采用的是VUVirtual User 场景Scenario双层抽象其核心是VU 是轻量级 JS 执行上下文不是 OS 线程也不是协程而是由 Go Runtime 管理的隔离 JS 引擎实例。这意味着什么我们来看一个典型场景配置export const options { scenarios: { default: { executor: ramping-vus, startVUs: 10, stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 20s, target: 0 }, ], gracefulRampDown: 30s, exec: default, }, }, };这里ramping-vus执行器并不意味着“启动 100 个线程”而是告诉 K6 的调度器“请在我指定的时间段内动态调整活跃 VU 数量目标是 100 个”。每个 VU 在自己的 JS 上下文中执行default()函数这个函数可以包含任意逻辑登录 → 查询订单列表 → 随机点击一个订单 → 查看详情 → 退出。K6 的调度器只负责控制 VU 的启停节奏而每个 VU 内部的执行流包括sleep()、check()、group()完全由 JS 引擎同步执行没有异步回调陷阱。提示K6 中sleep(1)表示“当前 VU 暂停 1 秒”不是“整个进程休眠 1 秒”。这正是它能精准模拟用户思考时间Think Time的关键——真实用户不会在点击按钮后立刻刷新页面而是会停顿、阅读、再操作。而 JMeter 的“定时器”作用于整个线程容易导致所有请求被同步延迟失真严重。更关键的是 K6 的生命周期钩子设计setup()在所有 VU 启动前执行一次常用于预热缓存、生成全局测试数据、获取 OAuth Tokendefault()每个 VU 的主执行函数即“一个用户的一次完整旅程”teardown()在所有 VU 结束后执行一次用于清理资源、汇总报告、发送告警。这种设计天然支持“数据准备 → 并发执行 → 结果归档”的完整闭环。比如我们曾用setup()调用内部 API 批量创建 10 万个测试商品再让 200 个 VU 并发搜索这些商品整个过程无需外部脚本协调全部在一个.js文件里完成。2.1 VU 与迭代Iteration的本质区别新手常混淆 VU 和 Iteration。简单说VU 是并发单位Iteration 是执行次数单位。一个 VU 可以执行多次default()即多个 Iteration只要它没被调度器终止。例如export const options { vus: 10, iterations: 50, // 这表示启动 10 个 VU总共执行 50 次 default()即平均每个 VU 执行 5 次 };而如果写成export const options { vus: 10, duration: 1m, // 这表示启动 10 个 VU持续运行 1 分钟每个 VU 尽可能多地执行 default() };前者适合“固定工作量压测”如跑完 50 次下单流程后者适合“固定时长压测”如观察系统在 1 分钟高负载下的稳定性。二者不可混用选错会导致结果完全不可比。我在某次电商大促前压测中就因误用iterations导致实际并发远低于预期差点漏掉一个连接池耗尽的隐患——后来我把这个判断逻辑封装成一个 CLI 工具在 CI 流水线里自动校验配置合法性。2.2 场景编排如何用一个脚本覆盖多种用户画像真实业务中用户不是千篇一律的。有 70% 是浏览用户只查不买20% 是下单用户查加购支付10% 是售后用户查订单申请退货。K6 的scenarios支持按权重分配不同行为路径export const options { scenarios: { browse: { executor: constant-vus, vus: 70, duration: 5m, exec: browseFlow, tags: { user_type: browse }, }, buy: { executor: constant-vus, vus: 20, duration: 5m, exec: buyFlow, tags: { user_type: buy }, }, afterSale: { executor: constant-vus, vus: 10, duration: 5m, exec: afterSaleFlow, tags: { user_type: after_sale }, }, }, };注意tags字段——它会在所有指标HTTP 请求、checks、custom metrics上自动打标。这样在 Grafana 里就能切片分析“售后用户的平均响应时间是否显著高于浏览用户”、“下单流程中支付接口的失败率是否集中在某个地域节点” 这种维度下钻能力是传统工具靠手动拆分日志才能勉强实现的。3. 从零写一个可落地的压测脚本以电商商品搜索接口为例我们以一个真实的电商搜索接口为例完整走一遍 K6 脚本开发流程。接口地址https://api.example.com/v2/search需携带Authorization: Bearer token请求体为 JSON{ keyword: 手机, page: 1, size: 20, filters: { brand: [Apple, Xiaomi], price_range: [1000, 5000] } }返回体含data.items[]和data.total。3.1 第一步环境隔离与配置管理K6 本身不提供环境变量管理但我们必须避免在脚本里硬编码https://staging.example.com或https://prod.example.com。正确做法是用__ENV对象读取环境变量并配合k6 run的-e参数# 开发环境 k6 run -e ENVdev -e BASE_URLhttps://staging-api.example.com search-test.js # 生产环境 k6 run -e ENVprod -e BASE_URLhttps://api.example.com search-test.js脚本开头统一处理import http from k6/http; import { check, sleep, group } from k6; import { Counter } from k6/metrics; // 读取环境变量带默认值防错 const BASE_URL __ENV.BASE_URL || https://staging-api.example.com; const ENV __ENV.ENV || dev; // 全局计数器统计不同环境下的请求总数 const envRequests new Counter(env_requests, { env: ENV }); export const options { stages: [ { duration: 30s, target: 50 }, { duration: 1m, target: 100 }, { duration: 30s, target: 0 }, ], }; export default function () { // 每次请求前记录环境标签 envRequests.add(1, { env: ENV }); group(Search Flow, () { const params { headers: { Content-Type: application/json, Authorization: Bearer ${getAuthToken()}, // token 获取逻辑见下文 }, }; const payload JSON.stringify({ keyword: randomKeyword(), page: Math.floor(Math.random() * 5) 1, // 随机页码 1~5 size: 20, filters: { brand: randomBrands(), price_range: [1000, 5000], }, }); const res http.post(${BASE_URL}/v2/search, payload, params); // 关键断言状态码、响应时间、数据结构 const checks check(res, { status is 200: (r) r.status 200, response time 800ms: (r) r.timings.duration 800, has items array: (r) r.json().data?.items instanceof Array, total 0: (r) r.json().data?.total 0, }); // 自定义指标按状态码分桶统计 if (res.status 400 res.status 500) { http.setResponseCallback((res) { console.log(Client error: ${res.status} ${res.body}); }); } sleep(1); // 模拟用户阅读结果页的思考时间 }); }注意http.setResponseCallback是 K6 2.x 新增的调试利器仅在本地开发时启用避免在 CI 中打印海量日志。它比console.log(res.body)更安全因为不会阻塞主线程。3.2 第二步Token 管理与认证复用真实项目中Authorization往往需要动态获取。我们不能让每个 VU 都去调/login拿新 Token会造成认证服务压力也不能全用一个 Token无法模拟多用户行为。K6 的推荐方案是在setup()中批量获取一批 Token存入全局数组VU 启动时轮询使用。// setup() 返回的对象会作为参数传给 default() export function setup() { const tokens []; const userCount 100; // 预生成 100 个用户 Token for (let i 0; i userCount; i) { const loginRes http.post( ${BASE_URL}/auth/login, JSON.stringify({ username: testuser${i}, password: 123456 }), { headers: { Content-Type: application/json } } ); if (loginRes.status 200) { const token loginRes.json().access_token; tokens.push(token); } else { console.warn(Failed to get token for user ${i}: ${loginRes.status}); } } return { tokens }; } export default function (data) { // data 是 setup() 返回的对象 const token data.tokens[__VU % data.tokens.length]; // 轮询使用避免越界 // 后续请求用 token... }这里__VU是 K6 内置变量表示当前 VU 的序号从 1 开始。用取模运算实现负载均衡确保 100 个 VU 均匀使用 100 个 Token。实测下来这种方式比“每个 VU 自己登录”减少 92% 的认证请求且完全符合“多用户并发”场景。3.3 第三步数据构造与真实性保障搜索关键词不能全是手机否则会触发缓存穿透或 CDN 缓存测不出真实后端压力。我们构建一个分层词库const KEYWORD_CATEGORIES { electronics: [手机, 笔记本电脑, 耳机, 智能手表], home: [空调, 冰箱, 洗衣机, 扫地机器人], beauty: [面膜, 精华液, 防晒霜, 口红], }; const BRANDS { electronics: [Apple, Xiaomi, Samsung, Huawei, OPPO], home: [Midea, Haier, Panasonic, Daikin], beauty: [Lancôme, Estée Lauder, Shiseido, The Ordinary], }; function randomKeyword() { const category Object.keys(KEYWORD_CATEGORIES)[ Math.floor(Math.random() * Object.keys(KEYWORD_CATEGORIES).length) ]; const keywords KEYWORD_CATEGORIES[category]; return keywords[Math.floor(Math.random() * keywords.length)]; } function randomBrands() { const category Object.keys(KEYWORD_CATEGORIES)[ Math.floor(Math.random() * Object.keys(KEYWORD_CATEGORIES).length) ]; const brands BRANDS[category]; const count Math.floor(Math.random() * 3) 1; // 随机选 1~3 个品牌 const selected []; for (let i 0; i count; i) { selected.push( brands[Math.floor(Math.random() * brands.length)] ); } return selected; }这种构造方式保证了关键词分布符合真实流量比例电子类占 45%家居占 30%美妆占 25%品牌组合随机但合理不会出现“空调 口红”这种无效过滤每次请求的 payload 都是唯一且不可预测的有效绕过 CDN 和 Redis 缓存。我们在某次压测中发现当关键词固定为手机时QPS 达到 1200但切换为真实词库后QPS 骤降至 780——因为后端缓存命中率从 92% 降到 65%这才暴露出数据库慢查询的真实瓶颈。4. 指标解读与根因定位不只是看 P95 和错误率K6 默认输出的摘要报告Summary Report只显示http_req_duration的 P95、http_req_failed等基础指标。但这远远不够。真正的压测价值在于通过指标组合定位系统瓶颈在哪儿。4.1 必须关注的 5 类核心指标指标类别K6 内置指标名业务含义健康阈值异常信号请求耗时http_req_duration端到端 HTTP 延迟P95 500msP95 突增 P50 平稳 → 后端 GC 或锁竞争连接建立http_req_connectingTCP 握手耗时P95 50ms突增 → DNS 解析慢 / 网络抖动 / 客户端连接池不足TLS 握手http_req_tls_handshakingHTTPS 加密协商P95 100ms突增 → 证书链异常 / TLS 版本不兼容等待服务器响应http_req_waiting从发送完请求到收到第一个字节的时间P95 300ms突增 → 后端处理慢 / 数据库慢查询 / 外部依赖超时传输耗时http_req_sendinghttp_req_receiving请求体发送 响应体接收总和 100ms突增 → 网络带宽打满 / 响应体过大提示http_req_waiting是最关键的诊断指标。如果它占http_req_duration的 80% 以上说明瓶颈 100% 在服务端如果http_req_connecting占比高则优先排查网络层。我们曾用这个方法快速定位一个诡异问题压测中http_req_durationP95 是 1.2s但http_req_waitingP95 是 1.15s而http_req_connectingP95 是 40ms。这说明请求发出去后服务端花了 1.15s 才开始处理。进一步查服务端日志发现是某个中间件的线程池被上游一个死循环任务占满导致新请求排队——这个结论在 3 分钟内就确认了而不用翻几十 GB 的全链路日志。4.2 自定义指标量化业务逻辑健康度K6 允许你定义任意指标这是超越传统工具的核心能力。比如我们关心“搜索结果相关性”是否随压力增大而下降import { Trend } from k6/metrics; // 定义自定义趋势指标 const relevanceScore new Trend(search_relevance_score); export default function () { const res http.post(...); if (res.status 200) { const data res.json(); const items data.data?.items || []; // 简单相关性打分关键词在标题中出现的次数 / 商品总数 const keyword JSON.parse(res.body).keyword; let score 0; for (const item of items) { if (item.title item.title.toLowerCase().includes(keyword.toLowerCase())) { score 1; } } relevanceScore.add(score / items.length); } }这个指标会出现在所有输出格式中。在 Grafana 里我们可以画出search_relevance_score随并发增长的变化曲线——如果它从 0.92 降到 0.35说明高负载下搜索算法降级了这比单纯看错误率更有业务价值。4.3 日志与追踪如何把 K6 接入现有可观测体系K6 原生支持 OpenTelemetry。只需在启动时加参数k6 run --experimental-execution-environment --out otel \ -e OTEL_EXPORTER_OTLP_ENDPOINThttp://otel-collector:4317 \ search-test.js它会自动为每个 HTTP 请求生成 Span包含http.method,http.url,http.status_codehttp.request_content_length,http.response_content_lengthk6.vu,k6.iteration,k6.scenario自定义 Tag通过params.tags传入这样你就可以在 Jaeger 或 Zipkin 里直接看到“第 87 个 VU 在第 3 次迭代中调用/v2/search时http.waiting耗时 1.2s期间调用了db.query和cache.get两个子 Span”。我们曾用此能力发现某个接口的http.waiting高但db.query耗时只有 20ms而cache.get耗时 1.1s——顺藤摸瓜查到是 Redis 连接池配置过小最大连接数只有 10200 个 VU 争抢导致大量排队。5. CI/CD 集成与质量门禁让压测成为发布流水线的守门员压测不能只在大促前做一次。我们把它变成每日构建的必过环节任何合并到main分支的代码必须通过基线压测否则禁止发布。5.1 构建可复现的压测基线基线不是“随便跑一次”而是严格定义的黄金标准环境专用压测集群与生产同规格但隔离网络数据全量脱敏生产数据快照每天凌晨自动同步脚本Git Tag 锁定如k6-baseline-v2.3.1参数vus100,duration2m,thresholds严格校验K6 的thresholds是质量门禁的核心export const options { thresholds: { // 关键业务指标必须达标 http_req_duration{expected_response:true}: [p(95)500], http_req_failed: [rate0.01], // 错误率 1% http_req_waiting: [p(90)300], // 后端处理必须快 // 非关键但需预警 http_req_connecting: [p(95)100], checks{type:relevance}: [rate0.8], // 相关性得分 80% }, };当k6 run执行完毕它会返回非零退出码如exit code 101如果任一阈值不满足。在 GitHub Actions 中我们这样写- name: Run K6 Baseline Test run: | k6 run --quiet \ -e BASE_URLhttp://test-cluster \ --out jsonreport.json \ ./tests/baseline/search-test.js # 若阈值失败k6 自动 exit 101Action 将失败5.2 压测报告自动化归档与对比每次压测后我们用 Python 脚本解析report.json提取关键指标存入 MySQL 表idcommit_hashbranchtimestampp95_durationerror_ratewaiting_p90env123abcdef123main2024-05-20 14:224820.003287staging然后在内部 Dashboard 上画出“P95 延迟趋势图”自动标注每次 PR 合并点。如果某次合并后 P95 上升超过 15%系统自动创建 Issue 相关开发者并附上前后两次压测的详细对比报告Diff 报告。这个机制让我们在 2023 年拦截了 23 次潜在性能退化其中最典型的是一个看似无害的“增加日志字段”提交导致序列化耗时增加 40msP95 从 420ms 升至 490ms——若未拦截上线后将导致大促期间 30% 的用户超时。5.3 实战避坑那些文档里不会写的血泪教训坑1http.batch()的并发陷阱初学者喜欢用http.batch()一次性发 10 个请求以为能提升吞吐。但 K6 的batch是在单个 VU 内并发而服务端看到的是 10 个独立连接。这会导致① 客户端连接数暴涨100 VU × 10 1000 连接② 服务端线程池瞬间被打满。正确做法用for循环 sleep()模拟真实用户串行操作或用多个 VU 分担。坑2check()里不要做耗时操作check()函数必须在毫秒级完成否则会拖慢整个 VU。曾有人在check()里调用JSON.parse(res.body)两次一次取data.total一次取data.items导致单次请求耗时增加 12ms。正确做法const json res.json();一次解析多次复用。坑3Docker 运行时的时区与 DNS 问题k6官方镜像基于alpineDNS 解析默认用musl libc在某些 Kubernetes 环境下会间歇性失败。解决方案启动容器时加--dns 8.8.8.8或改用k6:latest-slim基于 Debian。时区问题则加-e TZAsia/Shanghai。坑4setup()中的大对象内存泄漏setup()返回的对象会一直驻留在内存中供所有 VU 访问。如果在里面fs.readFileSync(1GB-file.json)100 个 VU 会共享这 1GB但 K6 的 JS 引擎 GC 不会及时回收。正确做法setup()只做轻量初始化大数据用流式读取或分片加载。最后分享一个小技巧我们把所有 K6 脚本的options配置抽离成config.js用import config from ./config.js引入。这样同一套脚本可以无缝切换“冒烟测试”10 VU、“基线测试”100 VU、“峰值测试”500 VU三种模式只需改一行import config from ./config.prod.js。三年来这套机制让我们压测准备时间从平均 3 天缩短到 2 小时真正实现了“性能左移”。
相关文章
Paginated Report实战：打造打印就绪的合规级分页报表
1. 什么是真正的“打印就绪”报告？我为什么在三年前就放弃了用Power BI Desktop硬凑报表你有没有遇到过这种场景：老板发来一份Excel格式的月度销售汇总表，要求“原样复刻到Power BI里”，还特别强调“表格边框要对齐”、“页眉页脚…
昇腾CANN cann-recipes-spatial-intelligence 仓：空间智能点云推理实战
前言 你做一个无人机避障或者机器人SLAM，需要处理点云数据。原始点云一来就是几十万甚至上百万个点，用CPU处理，一帧就要200ms，30FPS根本不可能。 cann-recipes-spatial-intelligence 是 CANN 面向空间智能（3D感知、SLA…
从零搭建Lovable保险系统，手把手实现监管沙盒对接、实时核保引擎与客户情感化交互模块
更多请点击： https://kaifayun.com 第一章：Lovable保险系统的设计哲学与架构全景 Lovable保险系统并非追求功能堆砌的庞然大物，而是以“可信赖、可演进、可共情”为内核构建的现代保险平台。其设计哲学根植于三个关键信条：用户意…
Keil MDK工程里printf中文正常，一换编辑器就乱码？手把手教你排查编码‘隐形杀手’
Keil MDK与外部编辑器编码冲突全解析：从乱码诊断到系统化解决方案当你从Keil MDK切换到其他编辑器时，是否遇到过这样的场景：原本正常显示的中文字符突然变成了一堆毫无意义的乱码？这种编码不一致问题就像潜伏在开发环境中的"…
别再只会点灯了！用STM32CubeMx配置GPIO输出模式（推挽/开漏）的实战避坑指南
STM32 GPIO输出模式深度解析：从LED调光到外设驱动的实战指南引言当你在STM32项目中发现LED亮度异常，或者无法驱动外部继电器时，问题往往出在GPIO输出模式的选择上。很多初学者在掌握了基本的点灯操作后，对推挽(Push-Pull)和开漏(O…
学Simulink——开关磁阻电机（SRM）的四象限运行与转矩脉动抑制仿真
目录 手把手教你学Simulink——开关磁阻电机（SRM）的四象限运行与转矩脉动抑制仿真 一、背景与挑战 1.1 为什么 SRM “不好驯服”？ 1.2 核心痛点与四象限制动目标 二、系统架构与核心控制推导 2.1 整体架构：从“磁链查表”到“角域四象限换相” 2.2 核心数学推导：SRM…
Java程序设计(第3版)第四章——方法的重载
方法的重载 1.在一个类中，我们可以定义一系列的方法，这些方法的方法名相同，参数列表不同，这种语法被称为方法的重载(OverLoad) 例：2.语法要求 (1)方法名相同 (2)形式参数列表不同个数、顺序、类型 (3)返回值类型、修饰…
对比直接使用官方API体验Taotoken在延迟与路由容灾方面的实际感受
🚀 告别海外账号与网络限制！稳定直连全球优质大模型，限时半价接入中。 👉 点击领取海量免费额度 对比直接使用官方API体验Taotoken在延迟与路由容灾方面的实际感受 1. 从单一端点转向聚合服务的背景 在开发基于大模型的应用时&a…
终极音频解密指南：3步轻松转换QQ音乐加密文件为通用格式
终极音频解密指南：3步轻松转换QQ音乐加密文件为通用格式 【免费下载链接】QMCDecode QQ音乐QMC格式转换为普通格式(qmcflac转flac，qmc0,qmc3转mp3, mflac,mflac0等转flac)，仅支持macOS，可自动识别到QQ音乐下载目录，默认…
Claude Code Skill动态发现机制全解析：为什么你的AI会自动执行代码
文章目录前言一、那个让我怀疑AI成精的自动commit事件二、静态注入：Claude偷偷给模型塞的小纸条三、Skill工具：模型自己给自己发指令的自导自演四、动态注入：Skill集合变了怎么办？五、语义匹配注入：当Skill多到烧不起t…
ssm高校普法系统（10101）
有需要的同学，源代码和配套文档领取，加文章最下方的名片哦 一、项目演示 项目演示视频 二、资料介绍 完整源代码（前后端源代码SQL脚本）配套文档（LWPPT开题报告/任务书）远程调试控屏包运行一键启动项目&…
强化学习策略参数调节方法及值迭代算法实现 CS188 Proj3 学习笔记
强烈推荐的更好的阅读体验 Q1.Value Iteration 第一个问题是最基础的值迭代实现，这个问题没有什么难度，主要就是一边看着公式一遍敲代码复现。可以先回顾一下Note8中的Value Iteration框架.唯一唯一需要注意的就是需要使用的是batch版本，而…
施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录
更多请点击： https://codechina.net 第一章：施工现场安全事故预警准确率达94.6%？——解密某央企AI Agent边缘计算部署架构与3个月落地实录 在华北某大型地铁盾构施工现场，一套轻量化AI Agent系统于2024年Q2完成全栈部署ÿ…
附录 B：术语表
本术语表面向“从 MM 到 HMM”专栏阅读过程中的快速查阅。它不是内核 API 手册，而是把文章中反复出现的概念放到同一张地图上：先给出直观含义，再说明它在 Linux MM/HMM 语境里的作用。建议阅读方式： 初读专栏时，把它当…
Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表·行业首曝）
更多请点击： https://kaifayun.com 第一章：Midjourney渐变美学的神经渲染原理（附RGB-HSV-LCH三空间渐变映射对照表行业首曝） Midjourney 的渐变美学并非传统插值实现，而是由其隐式神经渲染器（Implicit Neu…
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案
MPC-BE：基于DirectShow架构的专业级开源媒体播放解决方案 【免费下载链接】MPC-BE MPC-BE – универсальный проигрыватель аудио и видеофайлов для операционной системы Windows. 项目地址:…
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南
如何快速计算3D模型体积和重量：STL-Volume-Model-Calculator终极指南 【免费下载链接】STL-Volume-Model-Calculator STL Volume Model Calculator Python 项目地址: https://gitcode.com/gh_mirrors/st/STL-Volume-Model-Calculator 你是否曾经为3D打印项目…
通过Taotoken CLI工具一键配置团队开发环境与模型密钥
通过Taotoken CLI工具一键配置团队开发环境与模型密钥 1. CLI工具安装与基本使用 Taotoken提供的CLI工具可通过npm全局安装或直接使用npx运行。对于需要频繁使用CLI的团队，推荐全局安装： npm install -g taotoken/taotoken对于临时使用或项目级配置&a…