规模验证与容量规划
先用五台设备确认采集和连接，再在独立测试工程中扩大负载。容量取决于协议、点位、扫描周期和下游业务，应使用自己的配置验证。
按下面四步完成测试；查看资源占用可直接看1000 台设备与 100 万变量同次实测。
1. 建立五台设备的基线
进入 开发配置 → 采集配置 → 变量工具栏“更多” → 测试数据，选择“普通测试数据”。在独立工程中操作，生成会追加对象，再次提交不会覆盖上一批。
- 生成 2 台设备、20 个变量，关闭“启动 Modbus Slave 仿真器”。没有现成从站时，配置应存在但采集离线。
- 使用同一端点追加 3 台设备、30 个变量，这次开启内置仿真器。工程应累计为 5 条通道、5 台设备、50 个变量。
- 等待源端出现五个客户端，逐台确认设备在线、成功计数增长。源值可以为零，应同时检查质量和新的采集时间。
- 停止同一源，确认连接释放、设备离线且配置仍在；再启动原源，检查相同对象重新连接并产生新采样。
通过标准： 五台设备都有新采样和成功增量，停止与恢复后仍是原来的对象。保存成功或第一页显示绿色，都不能代替这项检查。
测试数据字段与变量分配规则
| 参数 | 填写方法 |
|---|---|
| 变量数量 | 本批所有设备的变量总数；不是每台设备各自的数量。 |
| 设备数量 | 本批新增的逻辑设备数。普通测试数据为每台设备建立独立 TCP 客户端通道。 |
| 从站地址 | 实际提供数据的 Modbus 服务端点；不是 Runtime 的 Web 地址。 |
| 启动 Modbus Slave 仿真器 | 开启时使用内置源；关闭时仍生成配置，需要已有从站才能在线。 |
20 个变量、2 台设备通常分为每台 10 个。不能整除时，末台承接余数；设备数量大于变量数量时，实际变量总数会至少覆盖设备数量。规模测试优先使用可整除组合。
请求异常时先核对实际已创建的数量，避免再次生成造成重复追加。扩大规模前，确认授权容量、端口权限及源端连接额度满足计划。
2. 检查连接配额
内置源的最大客户端数限制整个实例，单 IP 客户端数限制同一来源 IP，后者不能超过总额度。多个逻辑设备共用本机源时，两项都要覆盖计划连接数，并留出维护余量。
停止源端，修改并保存配额，重新打开确认，再启动观察。例如千连接的本机验证，可明确将总量和单 IP 额度都设置为 1024。
用五个客户端区分总额度与单 IP 限制
| 总额度 / 单 IP 额度 | 观察结果与判断 |
|---|---|
4 / 4 | 同一 IP 的五个客户端只能竞争四个额度，不能单独归因于某一个限制。 |
8 / 2 | 总容量足够；实际仅有两个同 IP 会话时，检查单 IP 拒绝和其余设备状态。 |
8 / 8 | 应恢复五个连接及全部设备的新采样。允许八个连接不表示已经建立八个。 |
总连接限制不一定增加安全拒绝计数。恢复后累计拒绝数也不必归零，应比较本次观察窗口的增量。
CPU 有余量时仍须检查连接额度；连接被拒绝会直接影响采集结果。
3. 扩大规模并记录结果
使用空白工程，一次生成 1000 台设备、1000 条独立 TCP 通道和 1000000 个变量，每台设备 1000 点。连接和变量负载在同一个工程中同时运行，测量期间保持全部设备、变量和源端连接在线。
这些是共用本机 Modbus 端点的逻辑设备。它们不能代表同等数量的物理仪表，也不能反映现场串口、远程网络或不同设备的响应时间。一千条独立连接与单通道并发一千分别验证。
分开记录创建与稳态阶段
- 记录初始配置数量、硬件、软件设置和源端能力。
- 单独测量批量创建时间，核对通道、设备和变量实际数量。
- 等全部设备与连接稳定，抽查首、中、末地址的有效新值。
- 使用 .NET 运行时诊断工具触发一次完整 Gen2 GC，确认回收结束、进程恢复执行，再等待 30 秒。负载保持运行，随后开始至少 300 秒的稳态窗口，每 2 秒记录 CPU 等进程资源。
- 保存窗口起止的全部设备及源端计数，确认每台设备成功计数增长，并检查失败、协议错误和安全拒绝增量。
- 稳态窗口结束后，再执行一次完整 GC，确认结束并等待 30 秒，读取仍在运行负载下的工作集和私有内存，同时核对设备、变量和连接数量。
创建、预热、GC 和 GC 后等待单独计时。CPU 统计从第一次完整 GC 结束并等待后开始，最终内存取第二次完整 GC 结束并等待后的读数。300 秒用于初步观察，长期稳定性按项目要求延长测试。
各项指标的含义与计算口径
| 指标 | 含义 |
|---|---|
| 在线变量数 | 某时刻的质量状态总量，不是每秒更新量。 |
| 协议请求速率 | 请求计数增量 ÷ 实际经过秒数。一个请求可能包含多个变量。 |
| 设备成功增量 | 设备任务成功处理次数，与协议请求分别记录。 |
| 执行间隔 | 调度输入；完整扫描还受包数、超时、重试和源端速度影响。 |
| 进程 CPU | 需说明是否按逻辑处理器数归一化；不能直接当成整台主机总占用。 |
| 工作集 / 私有内存 | 不同的进程内存指标，两者都不等于托管堆大小。 |
请求率与点刷新率分别测量。 一个请求可能覆盖多个变量，须结合完整扫描时间和各变量的新采样判断刷新能力。
1000 台设备与 100 万变量同次实测
本次在同一个工程中运行 1000 台设备、1000 条独立 TCP 通道和 100 万变量，每台 1000 点，执行间隔为 1000 毫秒。采集端与内置 Modbus 仿真器运行在同一宿主进程，共用一个本机源端点；宿主为 24 个逻辑处理器。
CPU 取完整 GC 结束并等待 30 秒后的 306.71 秒稳态窗口；窗口结束后再次完整 GC 并等待 30 秒，读取在载内存。测量值包含采集端和仿真器两部分负载。
| 指标 | 实测结果 |
|---|---|
| 稳态进程 CPU 平均 / 最大 | 15.36% / 20.75% |
| 完整 GC 后工作集 | 1264.97 MiB |
| 完整 GC 后私有内存 | 1076.73 MiB |
CPU 已按 24 个逻辑处理器归一化，为该宿主进程占用；内存为第二次完整 GC 后的单次读数。MiB 按 1024² 字节计算。稳态期间最低保持 1000 台设备、1000 个连接在线，全部设备成功计数增长，结束时 100 万变量在线。
查看采样与运行明细
| 指标 | 实测结果 |
|---|---|
| 本批创建耗时 | 约 164.75 秒，单独计时 |
| 稳态进程资源样本数 | 152，每约 2 秒一次 |
| 源端协议请求增量 | 3067409 |
| 设备成功计数增量 | 30638 |
| 设备失败 / 协议错误 / 安全拒绝增量 | 0 / 0 / 0 |
两次完整 GC 均确认 Gen2 回收结束及进程恢复执行。CPU 样本均位于第一次 GC 后的稳态窗口内，平均值按各次实际采样间隔加权；最终内存读数时，1000 台设备、100 万变量和 1000 个连接仍在线。
这些结果适用于上述本机仿真负载。现场网络、物理仪表及实际表达式、报警、转发和数据库业务，应按自己的配置重新验证；协议请求速率不能直接换算为变量刷新率。
4. 调优与验收
一次只调整一类条件，按相同观察窗口比较结果：
- 核对地址连续性和协议打包上限，减少不必要的单点请求。
- 设置满足业务新鲜度的周期，观察完整扫描时间。
- 按协议能力调整独立通道及并发，检查源端拒绝和失败增量。
- 加入实际使用的表达式、报警、规则、转发与数据库，重新测量完整业务负载。
- 验证正常运行、下游慢响应、断线补传和恢复后的积压处理。
图表、大量 Trace 日志和自动刷新都会增加测量负担。记录测量时启用的功能，使用相同的完整 GC、等待时间和观察窗口比较资源占用。
用单设备比较周期与打包
先只启用一台测试设备，保留其余对象但暂时禁用，确认源端只剩一个连接。以十个连续 Int16 保持寄存器为固定输入，每次保存后重新打开核对设置。
查看周期、打包、并发和超时的对照方法
| 对照参数 | 如何解释结果 |
|---|---|
执行间隔 1000 → 2000 → 1000 毫秒 | 比较实际请求和完整设备循环增量；短窗口受调度影响，请求率不要求机械减半。 |
FC3 最大读取保持寄存器数量 1 与 10 | 前者拆分更多读包，后者允许合并；实际仍受地址、类型和打包规则约束。 |
| 通道最大并发数 | 约束同一通道任务；独立连接数与单通道并发分别统计。 |
| 读写超时 | 增大超时通常不提高正常吞吐，可能延长故障等待。 |
| 失败重试 | 可能增加故障请求及占用；重试不等于新的设备成功或变量更新。 |
| 帧前时间、读写占空比 | 满足源端节奏并分配调度，连同包数影响完整扫描周期。 |
对照结束后恢复原设备使能和生产参数，再逐台核对连接、质量及新成功增量。配置细节见设备采集策略与 Modbus 主站。
结果记录
保存负载、周期、协议包设置、硬件及实际观察时长，列出稳态 CPU 平均与峰值、完整 GC 后的内存、失败增量和全部设备结果。短时通过不能推导长期耐久或任意现场设备的容量。分配速率、GC 暂停及协议延迟分位数，需要另行采样后评价。
相关操作：批量配置 · 协议仿真器与连接配额。