性能测试接口测试CLI【免费下载链接】artilleryThe complete load testing platform. Everything you need for production-grade load tests. Serverless distributed. Load test with Playwright. Load test HTTP APIs, GraphQL, WebSocket, and more. Use any Node.js module.项目地址https://gitcode.com/gh_mirrors/ar/artillery点击查看免费下载WebSockets 提供全双工、低延迟的实时通信能力是聊天、实时推送、在线协作类服务的关键基础设施。本指南以仓库 examples/websockets 示例为核心完整演示如何用 Artillery 内置的 WebSockets 引擎engine: ws对一个ws://服务进行负载测试——包括启动被测服务、编写多场景压测脚本、用自定义函数生成动态消息负载并结合引擎源码理解send、wait、capture、match与超时机制的底层工作原理。读完后你可以直接把这套流程迁移到自己的实时服务压测任务中。示例概览一个完整的 WebSocket 压测闭环examples/websockets目录麻雀虽小、五脏俱全包含了从被测服务到压测脚本的完整闭环文件作用examples/websockets/app.js基于ws库实现的简易 WebSocket 服务器监听ws://localhost:8888examples/websockets/test.ymlArtillery 压测脚本定义了两个 WebSocket 测试场景examples/websockets/my-functions.js处理器processor提供生成随机分数的自定义函数examples/websockets/package.json依赖与脚本管理声明了ws依赖及server、test两个 npm 脚本被测的app.js逻辑非常简单——收到任何消息后原样回传echoconst WebSocket require(ws); const wss new WebSocket.Server({ port: 8888 }); wss.on(connection, (ws) { ws.on(message, (msg) { ws.send(msg); }); }); console.log(WebSockets server listening at ws://localhost:8888);虽然业务逻辑只有十几行但它足够承载压测场景每个虚拟用户建立连接、发送消息、接收回包正是评估真实 WebSocket 服务吞吐与延迟的最小可验证模型。第一步安装依赖并启动被测服务在examples/websockets目录下执行npm install该命令会安装 package.json 中声明的ws示例锁定在^7.4.6等依赖。安装完成后启动服务npm run servernpm run server等价于node app.js启动后终端会输出WebSockets server listening at ws://localhost:8888从这一步开始被测的 WebSocket 服务就绪可以接受 Artillery 虚拟用户virtual users的连接了。第二步运行压测脚本保持服务器运行另开终端在examples/websockets目录执行npx artillery run test.ymlnpx artillery run是 Artillery CLI 的核心入口CLI 实现位于 packages/artillery/lib/cmds/run.ts。压测结束后终端会输出该轮测试的摘要报告包含虚拟用户统计、每秒请求数以及响应时间分布等指标。如果你已经通过 npm 全局安装过 Artillery也可以直接使用artillery run test.yml或 package.json 中预置的npm test脚本效果一致。第三步逐行拆解 test.yml 压测脚本examples/websockets/test.yml 是本次压测的核心完整内容如下config: target: ws://localhost:8888/ processor: ./my-functions.js phases: - duration: 60 arrivalRate: 25 scenarios: - name: sending_a_string engine: ws flow: - send: Artillery - name: sending_object_from_function engine: ws flow: - function: createRandomScore - send: {{ data }}config 段target压测目标地址这里指定为ws://localhost:8888/。Artillery 的 ws 引擎会为每个虚拟用户基于该地址创建一条独立的 WebSocket 连接。processor指向处理器文件./my-functions.js该文件导出的函数可以被场景中的function步骤调用。这是 Artillery 通用的“自定义函数”机制——在 packages/artillery/lib/core/engine_ws.ts 中function步骤会通过this.config.processor[requestSpec.function]查找并执行对应函数。phases负载阶段定义。这里的配置是60 秒内每秒新增 25 个虚拟用户arrivalRate即整个测试峰值阶段约产生 1500 个虚拟用户连接。关于arrivalRate、arrivalCount、rampTo等更丰富的负载模型可参考 packages/types/schema/config/phases.js 中的定义。scenarios 段两个场景都通过engine: ws显式指定使用 WebSockets 引擎若省略engineArtillery 默认使用 HTTP 引擎sending_a_string连接建立后直接向服务端发送字符串Artilleryflow: - send: Artillery由于被测服务是 echo 服务器每个虚拟用户都会收到自己的消息回包。sending_object_from_function演示了“函数生成动态数据 模板变量发送”的组合拳flow: - function: createRandomScore - send: {{ data }}先调用处理器函数createRandomScore生成随机对象并写入虚拟用户上下文变量data随后通过{{ data }}模板语法把该对象序列化后发送出去。第四步用处理器函数生成动态负载examples/websockets/my-functions.js 中的createRandomScore是动态负载生成的关键module.exports { createRandomScore }; function createRandomScore(userContext, _events, done) { const data { timestamp: Date.now(), score: Math.floor(Math.random() * 100) }; // set the data variable for the virtual user to use in the subsequent action userContext.vars.data data; return done(); }要点解析处理器函数签名是(userContext, events, done)这是 Artillery 自定义函数的标准接口userContext携带当前虚拟用户的上下文与变量、events是事件发射器、done是完成回调也支持返回 Promise 的异步写法见下文。userContext.vars.data data将生成的随机对象写入虚拟用户变量。每个虚拟用户拥有独立的vars空间因此不同用户发送的消息互不干扰。函数返回后流程进入下一步send: {{ data }}。在引擎实现中engine_ws.ts发送前会先对 payload 做模板渲染template(payload, context)如果渲染结果是对象会先JSON.stringify再发送因此这里实际发出去的是类似{timestamp:1690000000000,score:42}的 JSON 字符串。从源码结构看引擎同时兼容回调式与 Promise 式处理器当processFunc.constructor.name Function时按回调调用否则按 Promise 处理见 engine_ws.ts 中function步骤的实现。这种“函数生成 模板发送”的模式是 Artillery 处理需要动态载荷如随机数据、按用户生成 token场景的标准做法。从源码看 ws 引擎的底层实现了解引擎内部的工作方式能帮你写出更高效的压测脚本。packages/artillery/lib/core/engine_ws.ts 实现了完整的 WebSockets 引擎核心流程如下场景编译三步管道每个场景被编译成async.waterfall串联的三个阶段compile方法zero读取配置构造 WebSocket 参数目标地址、子协议、代理等并发出started事件one为当前虚拟用户new WebSocket(wsArgs.target, wsArgs.subprotocols, wsArgs.options)建立真实连接等待open事件后把连接对象挂到context.ws后续 steps依次执行场景 flow 中的各步骤send、wait、function、think、log、loop等。场景结束时若连接仍存在会调用context.ws.close()优雅关闭——每次虚拟用户会话都拥有独立的 WebSocket 连接这正是模拟真实用户长连接压力的关键。send 与 wait一收一发两条指令send发送消息。发送前对 payload 做模板渲染对象会被JSON.stringify。发送成功后会发出websocket.messages_sent计数与websocket.send_rate速率事件。若发送失败会发出error事件并把该虚拟用户标记为失败。wait只等待服务端消息而不发送任何数据适用于纯监听型场景如服务端主动推送。测试用例 ws-engine.test.js 中的should wait for a websocket response without send验证了sendwait的混合流程。capture 与 match对回包做断言与提取当send或wait的 payload 中带有capture或match字段时引擎会注册onmessage处理器getMessageHandler收到的消息会先尝试JSON.parse成{ body: ... }结构解析失败则保留原始字符串match用 JSONPath 表达式断言回包字段是否等于期望值断言失败会产生Failed capture or match错误capture会把提取到的值写入context.vars供后续步骤使用match和capture默认是严格模式strict失败即中止该虚拟用户的后续流程可通过strict: false放宽见 packages/types/schema/engines/common.js 中SharedCaptureProperties的说明。测试用例should match a websocket response without capture演示了send附带match: { json: $.foo, value: bar }的写法并断言vusers.failed 0且websocket.messages_sent 1。响应超时三层兜底取值当步骤带有capture/match时引擎通过setTimeout实现响应超时超时后发出error并回调失败。超时值按优先级取自config.timeout || config.ws.timeout || 10默认秒即顶层timeout优先其次ws.timeout最后回落到 10 秒。测试用例 ws-engine.test.js 中有两组用例分别验证config.ws.timeout: 1与顶层config.timeout: 1在服务端延迟 2 秒回包时都能正确触发超时失败。loop / think / log / function与 HTTP 引擎一致的流程原语ws 引擎复用了引擎公共工具集engine_util位于 packages/artillery/lib/commons/engine_util.ts因此loop支持count/over/whileTrue、think思考时间默认取config.defaults.think、log、function等原语在 WebSocket 场景中同样可用。例如在 loop 内连续发送多条消息并逐条断言回包flow: - loop: - send: payload: ping match: { json: $.pong, value: pong } count: 5对应的测试用例should wait for multiple websocket responses in a loop断言 5 条消息全部发送成功。connect 定制与底层客户端选项引擎还支持在 flow 首步用connect定制连接行为engine_ws.ts 中的getWsInstanceconnect: { target: ws://... }为当前场景覆盖连接目标connect: { function: prepareWsArgs }调用处理器函数动态修改连接参数target、subprotocols、headers 等适合按虚拟用户动态构造连接信息配置层的ws.headers、ws.subprotocols、ws.proxy代理 URL会在创建连接时传入底层ws客户端。子协议也支持通过Sec-WebSocket-Protocol请求头声明但config.ws.subprotocols优先。对应的配置校验见 packages/types/schema/engines/websocket.js其中subprotocols目前限定为json、soap、wamp、xmpp四种取值proxy结构为{ url: ... }。ws 引擎内置指标压测报告里看什么引擎在收发消息时发出的事件最终会聚合进压测报告计数聚合逻辑见 packages/artillery/lib/core/ssms.ts其中websocket.messages_sent作为关键计数参与报告输出。ws 引擎专属指标如下指标类型含义触发位置websocket.messages_sentcounter发送的消息总数engine_ws.tssend步骤websocket.messages_receivedcounter接收到的消息总数getMessageHandlerwebsocket.send_raterate消息发送速率send步骤websocket.receive_raterate消息接收速率getMessageHandler配合vusers.created、vusers.completed、vusers.failed、errors.*等通用指标就可以评估连接建立成功率、消息吞吐和失败分布。例如errors.invalid_step会在流程步骤无法识别时出现测试用例should report an error if a step is not valid用拼错的sedn验证了这一行为见 ws-engine.test.js。进阶玩法清单基于上述源码能力你可以把示例扩展为更贴近生产的压测脚本按用户动态构造连接用connect.function在处理器中为每个虚拟用户生成带鉴权参数的连接地址或请求头。多消息会话用loop模拟“持续收发”的长连接行为并用wait处理服务端主动推送。回包断言与提取用match校验协议正确性用capture提取后续步骤需要的字段如服务端下发的消息 ID。超时控制按服务预期响应时间设置config.ws.timeout避免无响应连接长时间挂起拖慢测试。代理与子协议对需要通过代理访问的 WebSocket 服务配置ws.proxy.url需要协商特定子协议时配置ws.subprotocols。完整的可运行示例、处理器模板与压测脚本都在 examples/websockets 目录中WebSocket 引擎的完整实现见 packages/artillery/lib/core/engine_ws.ts类型校验见 packages/types/schema/engines/websocket.js引擎行为的自动化验证见 packages/artillery/test/core/acceptance/ws-engine.test.js。结合这些源码阅读你就能完全掌握 Artillery 压测 WebSocket 服务的全部细节。赞分享性能测试接口测试CLI【免费下载链接】artilleryThe complete load testing platform. Everything you need for production-grade load tests. Serverless distributed. Load test with Playwright. Load test HTTP APIs, GraphQL, WebSocket, and more. Use any Node.js module.项目地址https://gitcode.com/gh_mirrors/ar/artillery点击查看免费下载相关推荐Aptos 服务 k6 负载测试指南基于 TypeScript 对 Indexer gRPC 接口进行压测Aptos 服务 k6 负载测试指南基于 TypeScript 对 Indexer gRPC 接口进行压测 导读 loadtest k6 https://li区块链Web3使用 Artillery 自定义函数对 Twirp RPC 服务进行负载测试使用 Artillery 自定义函数对 Twirp RPC 服务进行负载测试 导读 Twirp https://link.gitcode.com/i/e019b性能测试接口测试CLI在 AWS CodeBuild 中运行 Artillery 负载测试buildspec 配置与 Socket.IO 压测实战在 AWS CodeBuild 中运行 Artillery 负载测试buildspec 配置与 Socket.IO 压测实战 本指南基于仓库中的 AWS Co性能测试接口测试CLI上一篇如何用Open Mercato透视与侧边栏定制你的专属工作台下一篇GetQzonehistory5分钟快速找回QQ空间全部历史说说的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考