开发工具物联网后端【免费下载链接】MQTTXA Powerful and All-in-One MQTT 5.0 client toolbox for Desktop, CLI and WebSocket.项目地址https://gitcode.com/gh_mirrors/mq/MQTTX点击查看免费下载MQTTX CLI 内置的bench与simulate系列命令为开发者在无需编写脚本的情况下即可完成连接、订阅、发布三个维度的负载生成与数据仿真。本文以 MQTTX CLI 1.13.0对应本仓库cli目录为基准完整讲解bench conn、bench pub、bench sub、simulate、ls --scenarios的配置参数、模板语法与源码级实现细节帮助读者正确设计有界bounded压测任务、理解吞吐量与消息条数的真实语义并掌握编写自定义数据模拟场景的方法。写在前面压测的边界与前提使用这些命令时负载生成或数据模拟是明确目标。在开始之前必须先确立目标 broker、允许使用的主题前缀、客户端数量、消息大小/发送速率、消息条数上限以及运行时长。MQTTX CLI 的默认值带有“危险”性质——bench系列默认创建1000 个连接、发布无上限--limit 0因此每次都应当显式提供边界。一个随手运行的快速示例并不等于容量基准测试。下文示例均假设127.0.0.1:1883上已存在一个完成授权的 broker。还有两条必须遵守的纪律给每个命令都包裹一个外部截止时间deadline。bench conn与bench sub在成功后保持活跃不会自行退出发布者的消息条数限制并不能覆盖“连接挂死”或“部分失败”的情形。配置文件的默认值可能通过~/.mqttx-cli/config提供 host、port、protocol 与凭据参见 configuration.md 中关于初始化与--load-options的说明显式 CLI 参数优先于默认值。连接与订阅基准测试bench conn批量建连mqttx bench conn -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --client-id probe-conn-%i --reconnect-period 0--count是客户端数量--interval是启动相邻两个客户端连接之间的延迟单位毫秒--client-id使用%i占位符生成互不冲突的客户端 ID。记录实际建立的连接数量与总建连耗时然后在截止时间点结束本次运行。从实现上看conn.ts 中的benchConn会按count循环创建 MQTT 客户端每建一个等待interval毫秒await delay(interval)并通过connectedCount累加成功连接数当connectedCount count时输出Created ${count} connections in ${(end - start) / 1000}s。这也解释了为什么文档要求“记录实际创建的连接数”——源码统计的是实际建连成功的数量而非配置的--count。bench sub批量订阅mqttx bench sub -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --client-id probe-sub-%i \ -t mqttx-test/load/%i -q 1 --verbose --reconnect-period 0订阅者要先于发布者启动并同时检查订阅被拒rejection的情况以及“全部就绪”这一聚合状态行。需要特别警惕 1.13.0 版本的一个坑All connections subscribed这行日志可能在只有部分订阅成功时出现。对应实现位于 sub.ts 的benchSub它统计subscribedCount每个客户端、每个主题的订阅结果都会计数只有当connectedCount count subscribedCount count * topic.length时才会打印就绪状态但打印条件是allSuccessfulSubs.length 0而失败订阅QoS 返回 2 被拒只是逐条输出subscriptionNegated并不会阻止这行日志的出现。因此判断订阅是否真正成功必须结合--verbose输出中逐条订阅的结果来综合判定。bench sub只报告接收总数与速率不会逐条解码并展示每条消息的 payload 内容。如果需要对 payload 做内容检查、文件保存、编解码或干净输出应使用普通sub命令参见 payloads.md 与 workflows.md。发布基准测试bench pub有界负载探针mqttx bench pub -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --message-interval 500 --limit 6 \ --client-id probe-pub-%i -t mqttx-test/load/%i -q 1 \ -m bounded load probe --verbose --reconnect-period 0关键参数语义与普通pub不同务必区分--message-interval短选项-im每个客户端各自的发布间隔单位毫秒粗略的期望速率offered rate≈count * 1000 / messageInterval消息/秒实际值还会受到 QoS 确认与调度的影响--limit短选项-L跨所有客户端的聚合消息条数上限而不是每个客户端的配额。源码 pub.ts 的multiPub直接印证了上述语义messageInterval被传入setInterval(..., messageInterval)作为每个客户端各自的发布定时器limit则在共享变量total上做聚合判断limit 0 total limit即退出。同时注意测量实际计数不要把配置速率等同于实际吞吐。两个实现细节值得注意multiPub会在所有配置的客户端都连接成功connectedCount count时置initialized true之后才开始真正发布——从client.on(connect)中if (!initialized || !client.connected ...) return的逻辑可见。因此任何一个客户端建连失败都可能让整个压测任务挂起这就是文档强调“必须保留外部 deadline”的原因。--verbose只改变统计行的输出方式非 verbose 用交互式 Signale 行内刷新verbose 用常规 log 逐行输出Published total: X, message rate: Y/s每 1 秒刷新一次速率rate每秒清零重新累加。消息来源随机字节与文件回放--payload-size 1KB可替代-m生成指定大小的随机字节。底层 payloadGenerator.ts 支持B/KB/MB/GB单位如1024B、1KB、2.5MB超过 MQTT 单条 256MB 上限MQTT_SINGLE_MESSAGE_BYTE_LIMIT会直接报错退出生成逻辑使用crypto.randomBytes。--file-read ./messages.txt --split把文件按换行符切分并为每个客户端回放切分后的每一段源码中每个连接会_.cloneDeep(splitedMessageArr)一份独立副本见 pub.ts。显式传--split PATTERN时该模式被解释为JavaScript 正则表达式末尾分隔符可能产生空消息。同样要保留外部 deadline 并检查汇总计数客户端进度不均可能导致 split 模式无法自然完成。split 模式下 CLI 会在splitLimit 切分条数 * count达到后自动退出打印All N messages from the file have been successfully sent。不带--split时整个文件作为重复发送的 payload。bench pub不接受普通pub的--stdin、--format、Protobuf 或 Avro 标志若需要这类编码后的字节流请提前把编码结果写入文件再读取。主题与客户端模板压测/模拟场景下的模板替换规则与普通命令存在差异容易踩坑客户端 ID 用--client-id短选项-I。注意短选项-i是连接间隔interval与普通conn/pub/sub中-i的含义完全不同。%i是从 1 开始的客户端索引客户端 ID 中若没有%i且count 1会自动追加_index后缀。这正是 getBenchClientId.ts 的实现count 1 !hasPlaceholder ? \${baseClientId}_${index} : baseClientId。基准测试的主题模板支持%i、%u已提供的用户名和%c模拟simulate还额外支持%sc场景名。模板请在 shell 中加引号防止被 shell 展开。1.13.0 的一个易错点bench pub与simulate用基础客户端 ID 模板替换%c源码中topicName.replaceAll(%c, clientId)此处clientId是未展开的原始模板而bench sub用的是最终按客户端展开后的 ID。因此要保证发布者与订阅者主题对齐应显式使用%i主题模板不要假设%c在两条路径上展开成同一个值。%u在没有提供用户名时保持不替换源码中username (topicName topicName.replaceAll(%u, username))。内置模拟场景与列出命令ls --scenarios列出场景mqttx ls --scenariosls只有在提供--scenarios短选项-sc时才列出内置场景它不会枚举 broker 的主题、客户端或保留消息。实现见 ls.ts动态读取cli/src/scenarios目录下所有.js文件以表格形式输出每个场景的name与description。以实际安装后ls --scenarios的输出为准不要假设某个特定版本一定带了哪些场景。本仓库当前内置四个场景文件名区分大小写与 scenarios 目录 一一对应场景文件数据形态weatherweather.ts模拟天气站 JSON 数据含季节/昼夜感知的温湿度、风速、气压、空气质量等字段teslatesla.ts模拟特斯拉车辆遥测 JSON含车辆状态、电量、行程、温控等字段smart_homesmart_home.ts智能家居场景数据IEMIEM.tsIEM 场景数据以weather场景为例其generator会为每个clientId缓存一份静态信息station_id、城市、经纬度等再叠加随时间/季节/昼夜变化的实时字段最终返回{ message: JSON.stringify(data) }见 weather.ts。simulate运行模拟mqttx simulate --scenario weather -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 1 --interval 100 --message-interval 500 --limit 3 \ --client-id probe-sim-%i -t mqttx-test/sim/%sc/%i -q 1 \ --verbose --reconnect-period 0正确的操作顺序是先用ls --scenarios发现场景 → 在目标主题上启动一个有界订阅者 → 再运行 simulate随后校验实际收到的消息条数与场景字段。要点模拟只负责生成 payload它不会创建设备、也不会配置 brokersimulate与bench pub共享同一套 count/rate/limit 语义两者在源码中都走multiPub仅通过commandType区分见 pub.ts并支持连接类与 MQTT 属性类选项simulate没有通用的--message、--format或--payload-size输入标志——消息内容完全由场景生成器决定。自定义场景脚本用 --file 代替 --scenariosimulate --file ./probe.js注意在普通pub/sub中-f表示 format这里语义不同可以加载自定义场景。脚本是可执行的 JavaScript会被直接加载进 CLI 进程执行因此运行前必须审查用户提供的脚本并严格遵守用户要求的主题与负载范围场景来源--scenario与--file只能二选一。加载机制见 simulate.tsloadSimulator校验文件扩展名必须为.js、generator必须是函数然后把 CLI 内置的 Faker 实例自动注入为第一个参数simulatorModule.generator(faker, options)。若--file与--scenario同时相关--file优先。generator 的契约一个 CommonJS 上下文即目录未被配置为type: module中的.js模块可以这样写module.exports { name: probe, description: Small sensor readings for an MQTT test, generator(faker, options) { return { message: JSON.stringify({ device: options.clientId, value: faker.number.int({ min: 0, max: 100 }), }), } }, }必须遵守的约定generator(faker, options)是必需的同步函数返回{ message, topic? }message必须是字符串或 BufferCLI 注入其内置的 Faker 实例以及当前客户端的 optionsoptions.clientId可拿到展开后的客户端 ID导出name这样%sc才有有意义的取值simulate中用%sc替换场景名见 pub.ts可选的author、version、description、dataFormat字段用于描述场景元数据返回的topic会覆盖 CLI 的主题模板——发布前务必审查这一返回值不要返回 Promise也不要把原始 JavaScript 对象直接当作 MQTT payload对象不会被自动序列化。运行自定义脚本mqttx simulate --file ./probe.js -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 1 --interval 100 --message-interval 500 --limit 3 \ --client-id probe-custom -t mqttx-test/sim/%sc -q 1 --reconnect-period 0版本相关的已知坑与结果报告1.13.0 的模拟命令对外宣传的是拼写错误的--maximun-reconnect-times但运行时读取的实际字段是maximumReconnectTimes源码中const { maximumReconnectTimes } options贯穿conn/pub/sub/bench全链路见 conn.ts、pub.ts。不要依赖那个错误拼写的标志来结束一次有限运行——一次性测试请使用--reconnect-period 0并强制设置墙钟截止时间只有场景确实需要时才保留重连。报告时应当区分并同时给出请求值与实际达成值客户端数、消息条数、QoS、payload 大小、耗时、观察到的速率/错误以及清理情况。订阅者的送达总数可以大于发布者的发布总数——当多个订阅者各自收到同一份发布时这是正常的扇出现象不代表发布者重复发消息。判断重复只能基于发布侧计数与订阅侧去重比对不能仅凭数字大小下结论。小结MQTTX CLI 的压测与模拟链路在设计上高度一致bench conn/bench sub/bench pub与simulate共享 count/interval/message-interval/limit 语义模板系统统一支撑%i、%u、%c、%sc占位符模拟场景则统一收敛到generator(faker, options)这一契约。牢牢记住三个原则即可安全使用始终显式设置边界连接数、速率、条数、deadline、以实际计数而非配置值为准、先审查脚本与主题模板再运行。更多与bench/simulate配合使用的命令连接配置、payload 编解码、故障诊断可继续阅读本技能包的 workflows.md、connections.md 与 troubleshooting.md。赞分享开发工具物联网后端【免费下载链接】MQTTXA Powerful and All-in-One MQTT 5.0 client toolbox for Desktop, CLI and WebSocket.项目地址https://gitcode.com/gh_mirrors/mq/MQTTX点击查看免费下载相关推荐kube-bench 命令与参数完全指南CIS Kubernetes Benchmark 检测的 CLI 实战kube bench 命令与参数完全指南CIS Kubernetes Benchmark 检测的 CLI 实战 kube bench 是依据 CIS Kube应用安全云原生Serial Studio MessagePack 数据解析从线缆格式到仪表盘通道的完整指南Serial Studio MessagePack 数据解析从线缆格式到仪表盘通道的完整指南 MessagePack 是一种紧凑的二进制序列化格式广泛用于嵌开发工具物联网后端Prisma 数据导出完整指南CLI 命令与原生 Export API 实战Prisma 数据导出完整指南CLI 命令与原生 Export API 实战 导读 本文围绕 Prisma 服务Prisma 1.x的 数据导出Data后端数据库GraphQL上一篇ES6粘性匹配终极指南如何用y标志提升正则表达式性能300%下一篇NSwag文档团队协作报告生成协作统计报告创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MQTTX CLI 压测与数据模拟实战指南：bench 与 simulate 命令的完整用法
开发工具物联网后端【免费下载链接】MQTTXA Powerful and All-in-One MQTT 5.0 client toolbox for Desktop, CLI and WebSocket.项目地址https://gitcode.com/gh_mirrors/mq/MQTTX点击查看免费下载MQTTX CLI 内置的bench与simulate系列命令为开发者在无需编写脚本的情况下即可完成连接、订阅、发布三个维度的负载生成与数据仿真。本文以 MQTTX CLI 1.13.0对应本仓库cli目录为基准完整讲解bench conn、bench pub、bench sub、simulate、ls --scenarios的配置参数、模板语法与源码级实现细节帮助读者正确设计有界bounded压测任务、理解吞吐量与消息条数的真实语义并掌握编写自定义数据模拟场景的方法。写在前面压测的边界与前提使用这些命令时负载生成或数据模拟是明确目标。在开始之前必须先确立目标 broker、允许使用的主题前缀、客户端数量、消息大小/发送速率、消息条数上限以及运行时长。MQTTX CLI 的默认值带有“危险”性质——bench系列默认创建1000 个连接、发布无上限--limit 0因此每次都应当显式提供边界。一个随手运行的快速示例并不等于容量基准测试。下文示例均假设127.0.0.1:1883上已存在一个完成授权的 broker。还有两条必须遵守的纪律给每个命令都包裹一个外部截止时间deadline。bench conn与bench sub在成功后保持活跃不会自行退出发布者的消息条数限制并不能覆盖“连接挂死”或“部分失败”的情形。配置文件的默认值可能通过~/.mqttx-cli/config提供 host、port、protocol 与凭据参见 configuration.md 中关于初始化与--load-options的说明显式 CLI 参数优先于默认值。连接与订阅基准测试bench conn批量建连mqttx bench conn -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --client-id probe-conn-%i --reconnect-period 0--count是客户端数量--interval是启动相邻两个客户端连接之间的延迟单位毫秒--client-id使用%i占位符生成互不冲突的客户端 ID。记录实际建立的连接数量与总建连耗时然后在截止时间点结束本次运行。从实现上看conn.ts 中的benchConn会按count循环创建 MQTT 客户端每建一个等待interval毫秒await delay(interval)并通过connectedCount累加成功连接数当connectedCount count时输出Created ${count} connections in ${(end - start) / 1000}s。这也解释了为什么文档要求“记录实际创建的连接数”——源码统计的是实际建连成功的数量而非配置的--count。bench sub批量订阅mqttx bench sub -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --client-id probe-sub-%i \ -t mqttx-test/load/%i -q 1 --verbose --reconnect-period 0订阅者要先于发布者启动并同时检查订阅被拒rejection的情况以及“全部就绪”这一聚合状态行。需要特别警惕 1.13.0 版本的一个坑All connections subscribed这行日志可能在只有部分订阅成功时出现。对应实现位于 sub.ts 的benchSub它统计subscribedCount每个客户端、每个主题的订阅结果都会计数只有当connectedCount count subscribedCount count * topic.length时才会打印就绪状态但打印条件是allSuccessfulSubs.length 0而失败订阅QoS 返回 2 被拒只是逐条输出subscriptionNegated并不会阻止这行日志的出现。因此判断订阅是否真正成功必须结合--verbose输出中逐条订阅的结果来综合判定。bench sub只报告接收总数与速率不会逐条解码并展示每条消息的 payload 内容。如果需要对 payload 做内容检查、文件保存、编解码或干净输出应使用普通sub命令参见 payloads.md 与 workflows.md。发布基准测试bench pub有界负载探针mqttx bench pub -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 2 --interval 100 --message-interval 500 --limit 6 \ --client-id probe-pub-%i -t mqttx-test/load/%i -q 1 \ -m bounded load probe --verbose --reconnect-period 0关键参数语义与普通pub不同务必区分--message-interval短选项-im每个客户端各自的发布间隔单位毫秒粗略的期望速率offered rate≈count * 1000 / messageInterval消息/秒实际值还会受到 QoS 确认与调度的影响--limit短选项-L跨所有客户端的聚合消息条数上限而不是每个客户端的配额。源码 pub.ts 的multiPub直接印证了上述语义messageInterval被传入setInterval(..., messageInterval)作为每个客户端各自的发布定时器limit则在共享变量total上做聚合判断limit 0 total limit即退出。同时注意测量实际计数不要把配置速率等同于实际吞吐。两个实现细节值得注意multiPub会在所有配置的客户端都连接成功connectedCount count时置initialized true之后才开始真正发布——从client.on(connect)中if (!initialized || !client.connected ...) return的逻辑可见。因此任何一个客户端建连失败都可能让整个压测任务挂起这就是文档强调“必须保留外部 deadline”的原因。--verbose只改变统计行的输出方式非 verbose 用交互式 Signale 行内刷新verbose 用常规 log 逐行输出Published total: X, message rate: Y/s每 1 秒刷新一次速率rate每秒清零重新累加。消息来源随机字节与文件回放--payload-size 1KB可替代-m生成指定大小的随机字节。底层 payloadGenerator.ts 支持B/KB/MB/GB单位如1024B、1KB、2.5MB超过 MQTT 单条 256MB 上限MQTT_SINGLE_MESSAGE_BYTE_LIMIT会直接报错退出生成逻辑使用crypto.randomBytes。--file-read ./messages.txt --split把文件按换行符切分并为每个客户端回放切分后的每一段源码中每个连接会_.cloneDeep(splitedMessageArr)一份独立副本见 pub.ts。显式传--split PATTERN时该模式被解释为JavaScript 正则表达式末尾分隔符可能产生空消息。同样要保留外部 deadline 并检查汇总计数客户端进度不均可能导致 split 模式无法自然完成。split 模式下 CLI 会在splitLimit 切分条数 * count达到后自动退出打印All N messages from the file have been successfully sent。不带--split时整个文件作为重复发送的 payload。bench pub不接受普通pub的--stdin、--format、Protobuf 或 Avro 标志若需要这类编码后的字节流请提前把编码结果写入文件再读取。主题与客户端模板压测/模拟场景下的模板替换规则与普通命令存在差异容易踩坑客户端 ID 用--client-id短选项-I。注意短选项-i是连接间隔interval与普通conn/pub/sub中-i的含义完全不同。%i是从 1 开始的客户端索引客户端 ID 中若没有%i且count 1会自动追加_index后缀。这正是 getBenchClientId.ts 的实现count 1 !hasPlaceholder ? \${baseClientId}_${index} : baseClientId。基准测试的主题模板支持%i、%u已提供的用户名和%c模拟simulate还额外支持%sc场景名。模板请在 shell 中加引号防止被 shell 展开。1.13.0 的一个易错点bench pub与simulate用基础客户端 ID 模板替换%c源码中topicName.replaceAll(%c, clientId)此处clientId是未展开的原始模板而bench sub用的是最终按客户端展开后的 ID。因此要保证发布者与订阅者主题对齐应显式使用%i主题模板不要假设%c在两条路径上展开成同一个值。%u在没有提供用户名时保持不替换源码中username (topicName topicName.replaceAll(%u, username))。内置模拟场景与列出命令ls --scenarios列出场景mqttx ls --scenariosls只有在提供--scenarios短选项-sc时才列出内置场景它不会枚举 broker 的主题、客户端或保留消息。实现见 ls.ts动态读取cli/src/scenarios目录下所有.js文件以表格形式输出每个场景的name与description。以实际安装后ls --scenarios的输出为准不要假设某个特定版本一定带了哪些场景。本仓库当前内置四个场景文件名区分大小写与 scenarios 目录 一一对应场景文件数据形态weatherweather.ts模拟天气站 JSON 数据含季节/昼夜感知的温湿度、风速、气压、空气质量等字段teslatesla.ts模拟特斯拉车辆遥测 JSON含车辆状态、电量、行程、温控等字段smart_homesmart_home.ts智能家居场景数据IEMIEM.tsIEM 场景数据以weather场景为例其generator会为每个clientId缓存一份静态信息station_id、城市、经纬度等再叠加随时间/季节/昼夜变化的实时字段最终返回{ message: JSON.stringify(data) }见 weather.ts。simulate运行模拟mqttx simulate --scenario weather -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 1 --interval 100 --message-interval 500 --limit 3 \ --client-id probe-sim-%i -t mqttx-test/sim/%sc/%i -q 1 \ --verbose --reconnect-period 0正确的操作顺序是先用ls --scenarios发现场景 → 在目标主题上启动一个有界订阅者 → 再运行 simulate随后校验实际收到的消息条数与场景字段。要点模拟只负责生成 payload它不会创建设备、也不会配置 brokersimulate与bench pub共享同一套 count/rate/limit 语义两者在源码中都走multiPub仅通过commandType区分见 pub.ts并支持连接类与 MQTT 属性类选项simulate没有通用的--message、--format或--payload-size输入标志——消息内容完全由场景生成器决定。自定义场景脚本用 --file 代替 --scenariosimulate --file ./probe.js注意在普通pub/sub中-f表示 format这里语义不同可以加载自定义场景。脚本是可执行的 JavaScript会被直接加载进 CLI 进程执行因此运行前必须审查用户提供的脚本并严格遵守用户要求的主题与负载范围场景来源--scenario与--file只能二选一。加载机制见 simulate.tsloadSimulator校验文件扩展名必须为.js、generator必须是函数然后把 CLI 内置的 Faker 实例自动注入为第一个参数simulatorModule.generator(faker, options)。若--file与--scenario同时相关--file优先。generator 的契约一个 CommonJS 上下文即目录未被配置为type: module中的.js模块可以这样写module.exports { name: probe, description: Small sensor readings for an MQTT test, generator(faker, options) { return { message: JSON.stringify({ device: options.clientId, value: faker.number.int({ min: 0, max: 100 }), }), } }, }必须遵守的约定generator(faker, options)是必需的同步函数返回{ message, topic? }message必须是字符串或 BufferCLI 注入其内置的 Faker 实例以及当前客户端的 optionsoptions.clientId可拿到展开后的客户端 ID导出name这样%sc才有有意义的取值simulate中用%sc替换场景名见 pub.ts可选的author、version、description、dataFormat字段用于描述场景元数据返回的topic会覆盖 CLI 的主题模板——发布前务必审查这一返回值不要返回 Promise也不要把原始 JavaScript 对象直接当作 MQTT payload对象不会被自动序列化。运行自定义脚本mqttx simulate --file ./probe.js -h 127.0.0.1 -p 1883 -l mqtt -V 5.0 \ --count 1 --interval 100 --message-interval 500 --limit 3 \ --client-id probe-custom -t mqttx-test/sim/%sc -q 1 --reconnect-period 0版本相关的已知坑与结果报告1.13.0 的模拟命令对外宣传的是拼写错误的--maximun-reconnect-times但运行时读取的实际字段是maximumReconnectTimes源码中const { maximumReconnectTimes } options贯穿conn/pub/sub/bench全链路见 conn.ts、pub.ts。不要依赖那个错误拼写的标志来结束一次有限运行——一次性测试请使用--reconnect-period 0并强制设置墙钟截止时间只有场景确实需要时才保留重连。报告时应当区分并同时给出请求值与实际达成值客户端数、消息条数、QoS、payload 大小、耗时、观察到的速率/错误以及清理情况。订阅者的送达总数可以大于发布者的发布总数——当多个订阅者各自收到同一份发布时这是正常的扇出现象不代表发布者重复发消息。判断重复只能基于发布侧计数与订阅侧去重比对不能仅凭数字大小下结论。小结MQTTX CLI 的压测与模拟链路在设计上高度一致bench conn/bench sub/bench pub与simulate共享 count/interval/message-interval/limit 语义模板系统统一支撑%i、%u、%c、%sc占位符模拟场景则统一收敛到generator(faker, options)这一契约。牢牢记住三个原则即可安全使用始终显式设置边界连接数、速率、条数、deadline、以实际计数而非配置值为准、先审查脚本与主题模板再运行。更多与bench/simulate配合使用的命令连接配置、payload 编解码、故障诊断可继续阅读本技能包的 workflows.md、connections.md 与 troubleshooting.md。赞分享开发工具物联网后端【免费下载链接】MQTTXA Powerful and All-in-One MQTT 5.0 client toolbox for Desktop, CLI and WebSocket.项目地址https://gitcode.com/gh_mirrors/mq/MQTTX点击查看免费下载相关推荐kube-bench 命令与参数完全指南CIS Kubernetes Benchmark 检测的 CLI 实战kube bench 命令与参数完全指南CIS Kubernetes Benchmark 检测的 CLI 实战 kube bench 是依据 CIS Kube应用安全云原生Serial Studio MessagePack 数据解析从线缆格式到仪表盘通道的完整指南Serial Studio MessagePack 数据解析从线缆格式到仪表盘通道的完整指南 MessagePack 是一种紧凑的二进制序列化格式广泛用于嵌开发工具物联网后端Prisma 数据导出完整指南CLI 命令与原生 Export API 实战Prisma 数据导出完整指南CLI 命令与原生 Export API 实战 导读 本文围绕 Prisma 服务Prisma 1.x的 数据导出Data后端数据库GraphQL上一篇ES6粘性匹配终极指南如何用y标志提升正则表达式性能300%下一篇NSwag文档团队协作报告生成协作统计报告创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考