EMS Builder 在 AFE-E620 上的性能测试报告

报告版本： v1.0
测试日期： 2026-07-30 ～ 2026-07-31
报告日期： 2026-07-31
统计口径： 每场景采集 2,002 次，忽略首尾样本，仅统计 sample_no=2～2001 的 2,000 次有效资源样本
关联手册： Edge-EMS Builder 性能测试手册

一、性能结果概览

✅ AFE-E620 推荐运行场景：S2.5

在本轮 6 个实测场景中，S2.5 是任务达成率达到 99% 参考线的最高负载场景。AFE-E620 内存仅 982 MB，所有场景整机内存均已处于高位，内存是本设备的主要容量约束。推荐采用变化存储（数值不变时最迟 10 秒保存），并将以下负载作为当前已验证的推荐运行配置。

📡

2,000 点/秒
数据采集配置量

🧮

20 个
聚合运算

⚡

40 次/秒
Trigger 目标

☁️

10 次/秒
MQTT 任务目标

🤝

2 次/秒
协作任务

💾

变化存储
最迟 10 秒保存

🧠

26.24% / 45.54%
整机 CPU 平均 / P95

🗄️

80.01% / 86.10%
整机内存平均 / P95

⏱️

25 ms
Trigger P95

📨

56 ms
MQTT P95

每次 Trigger 执行代表 1 次设备控制、1 次本地告警与 MQTT 告警，以及 1 次聚合数据写入。Edge-EMS Builder 会根据设备内存为 PostgreSQL 分配资源，因此不同设备、数据库规模及缓存状态下的内存占用可能存在明显差异。AFE-E620 物理内存仅 982 MB，内存余量明显小于 AFE-E630，规划容量时应优先关注内存。

1.1 醒目结论

推荐 AFE-E620 按 S2.5 场景运行：2,000 点/秒、20 个聚合运算、40 次 Trigger/秒、10 次 MQTT/秒、2 次协作任务/秒，并启用 10 秒变化存储。

S2.5 实测 Trigger 为 39.96 次/秒、MQTT 为 9.98 次/秒，达成率分别为 99.91% 和 99.82%；Trigger / MQTT P95 分别为 25 ms 和 56 ms。整机 CPU P95 为 45.54%，整机实际内存 P95 为 86.10%，本场景出现 8 次采样超时。

面向长期生产运行，建议在 S2.5 已测负载上保留约 20% 工程余量，初始容量可按不高于约 1,600 点/秒、32 次 Trigger/秒、8 次 MQTT/秒、2 次协作任务/秒规划。该建议是由实测配置折算的工程值，并非单独执行过的测试场景；正式上线前仍应使用项目实际脚本、消息大小和数据库历史量复测。

1.2 各场景状态

图标	场景	结论
🟢	S1	基准场景通过，达成率 100%；但整机内存平均已达 74.02%，内存基线偏高。
🟡	S2	实时存储下 Trigger / MQTT 达成率为 98.65% / 98.76%，略低于 99% 参考线，并出现 34 次采样超时。
🟢	S2.5	达到 99% 参考线的最高负载场景，作为 AFE-E620 当前推荐场景。
🔴	S3	未通过：Trigger / MQTT 达成率仅 43.08% / 44.65%，时延显著恶化，出现 617 次采样超时。
🔴	S3.5	未通过：变化存储明显改善 S3 的表现，但达成率仍为 87.30% / 86.69%，低于 99% 参考线。
🔴	S6	严重过载：Trigger / MQTT 达成率仅 19.15% / 19.18%，出现 886 次采样超时。

二、结论摘要

本轮共测试 S1、S2、S2.5、S3、S3.5、S6 六个场景，其他场景不纳入数据表、比较和结论。
S2.5 在 2,000 点/秒配置负载下，Trigger 达成率为 99.91%，MQTT 达成率为 99.82%；Trigger / MQTT P95 分别为 25 ms 和 56 ms。
S2 与 S2.5 的业务负载相同。启用变化存储后，S2.5 的整机 CPU 平均值由 29.41% 降至 26.24%，P95 由 52.01% 降至 45.54%，Trigger 达成率由 98.65% 升至 99.91%。
S3 与 S3.5 的业务负载相同。启用变化存储后，Trigger 达成率由 43.08% 升至 87.30%，MQTT 达成率由 44.65% 升至 86.69%，整机 CPU P95 由 82.71% 降至 66.05%，但仍未通过；5,000 点/秒已超出 AFE-E620 的持续承载能力。
与 AFE-E630 对比：E630 可承载 S3.5（5,000 点/秒、90 次 Trigger/秒），E620 的已验证上限为 S2.5（2,000 点/秒、40 次 Trigger/秒）。内存差距（3.81 GB 对 982 MB）是主要差异来源。
各场景 Trigger 均存在约 10～11 秒的单次长尾；过载场景中长尾进一步放大，S3.5 的 Trigger 单次最大达 53,472 ms，MQTT 单次最大达 53,373 ms。
所有场景的整机内存平均值均超过 74%，S3 及以后的 P95 超过 91%；内存是 E620 全场景的共同瓶颈，需要持续监控。
本轮每个场景仅保留 2,000 秒（约 33 分 20 秒）有效样本，适合性能对比，但不能替代 72 小时稳定性测试。

三、统计口径

3.1 样本筛选

监控采用次数计数。每个场景的资源原始数据均包含 sample_no=1～2002：

忽略：sample_no = 1
统计：sample_no = 2～2001，共 2,000 次
忽略：sample_no = 2002

剔除首尾样本可避免开始和结束时不足完整一秒的数据进入统计。Trigger 与 MQTT 总体结果均以 2,000 秒为分母；即使某一秒没有任务记录，该秒仍计入平均处理量，避免只统计有数据秒而高估吞吐。

3.2 EMS Builder 整体范围

以下 5 个服务合并视为一个完整 Edge-EMS Builder：

服务	作用
`cb_core`	数据采集与核心通信
`cb_nginx`	CommBridge Web / 反向代理
`cb_backend`	CommBridge 后端
`ems_backend`	EMS Builder 计算、策略与业务逻辑
`ems_postgresql`	EMS Builder 数据存储

每个 sample_no 先合计 5 个服务，再从 2,000 个合计值计算平均、P95、P99 和峰值，不将各服务在不同时刻出现的独立峰值直接相加。

3.3 CPU、内存与任务时延

五服务 CPU 原始值采用单核等效百分比；AFE-E620 为 4 核设备，因此“Edge-EMS Builder 4 核等效 CPU”= 五服务 CPU 合计 ÷ 4。
“整机 CPU”使用工作簿中的 _system_total，表示全部 CPU 容量归一化后的 0～100% 占用，是判断设备容量的主要指标。
“Edge-EMS Builder 归属内存”是五个服务 cgroup 归属内存的合计；共享页和缓存可能被重复归属，因此该值可高于整机实际已用内存，不能直接除以物理内存作为容量占用率。
“整机实际内存”按 MemTotal - MemAvailable 计算，是判断物理内存余量的主要指标；本报告内存百分比按 MemTotal = 982 MB 计算。
Trigger / MQTT 的平均值和 P50、P95、P99 基于有效区间内的全部任务记录，不是每秒平均值的分位数。
各工作簿均通过“汇总前测试负载已关闭”校验，Trigger、MQTT 与 CommBridge 均在汇总前关闭并等待 30 秒。

四、测试对象与环境

项目	配置
设备型号	AFE-E620
CPU	Arm Cortex-A55，4 核
内存	982 MB DDR3
操作系统	JelinaOS，基于 Ubuntu 20.04
存储	eMMC
软件版本	待补充（本轮工作簿未记录，归档前需补录 CommBridge / EMS Builder / PostgreSQL 版本）
网络	局域网；MQTT / TCP
监控采样	每秒采集 1 次；每场景 2,002 次，统计中间 2,000 次
测试数据源	`perf_S1_20260730_101351.xlsx`、`perf_S2_20260730_105126.xlsx`、`perf_S2.5_20260730_113029.xlsx`、`perf_S3_20260730_152548.xlsx`、`perf_S3.5_20260731_122356.xlsx`、`perf_S6_20260731_173626.xlsx`

五、场景与负载

场景	数据采集	聚合运算	普通 Trigger	100 ms Trigger	Trigger 目标	MQTT 目标	协作任务	存储策略
S1	500 点/秒	10	10 次/秒	0	10 次/秒	5 次/秒	0 次/秒	实时
S2	2,000 点/秒	20	20 次/秒	2	40 次/秒	10 次/秒	2 次/秒	实时
S2.5	2,000 点/秒	20	20 次/秒	2	40 次/秒	10 次/秒	2 次/秒	变化存储（10 秒）
S3	5,000 点/秒	30	50 次/秒	4	90 次/秒	20 次/秒	10 次/秒	实时
S3.5	5,000 点/秒	30	50 次/秒	4	90 次/秒	20 次/秒	10 次/秒	变化存储（10 秒）
S6	5,000 点/秒	20	50 次/秒	10	150 次/秒	30 次/秒	15 次/秒	实时

“数据采集”是场景配置负载，场景定义沿用测试手册；工作簿未提供逐点采集成功数，也未记录逐场景配置明细，不能将配置值表述为已经独立验证的成功入库吞吐量。各场景 Trigger / MQTT 目标与工作簿中的达成率校验目标一致。

六、测试时间

场景	有效统计区间	有效时长
S1	2026-07-30 10:13:55 ～ 10:47:13	2,000 秒
S2	2026-07-30 10:51:30 ～ 11:24:48	2,000 秒
S2.5	2026-07-30 11:30:33 ～ 12:03:51	2,000 秒
S3	2026-07-30 15:25:51 ～ 15:59:09	2,000 秒
S3.5	2026-07-31 12:23:59 ～ 12:57:17	2,000 秒
S6	2026-07-31 17:36:29 ～ 18:09:47	2,000 秒

以上时间均为 UTC+8。

七、CPU 结果

7.1 EMS Builder 五服务合计（4 核等效）

状态	场景	平均	P95	P99	峰值
🟢	S1	9.87%	19.19%	27.73%	32.42%
🟡	S2	22.39%	41.93%	51.69%	110.22%
🟢	S2.5	19.86%	36.67%	47.88%	75.63%
🔴	S3	32.80%	57.33%	71.41%	115.84%
🔴	S3.5	32.25%	52.81%	64.87%	130.65%
🔴	S6	30.90%	63.74%	77.34%	99.06%

S2、S3、S3.5 的 Edge-EMS Builder 峰值分别为 110.22%、115.84%、130.65%，是单个采样窗口的瞬时值，对应五服务合计 CPU 时间超过 4 核常规容量（例如 S2 中 ems_backend 单服务单样本峰值达 402%）。结合采样超时判断，可能存在采样窗口跨期或突发调度，不将其视为可持续资源占用。

7.2 整机 CPU（全部 CPU 容量归一化）

状态	场景	平均	P95	P99	峰值
🟢	S1	15.27%	26.83%	34.00%	50.88%
🟡	S2	29.41%	52.01%	70.29%	100.00%
🟢	S2.5	26.24%	45.54%	58.41%	97.05%
🔴	S3	48.29%	82.71%	97.18%	100.00%
🔴	S3.5	41.32%	66.05%	90.63%	100.00%
🔴	S6	49.35%	88.33%	98.30%	100.00%

整机 CPU 是本报告判断设备 CPU 容量的主要依据。S2.5 的 P95 比 S2 低 6.47 个百分点；S3 及以后 P95 均超过 66%，且峰值达到 100%，CPU 已进入饱和区。

八、内存结果

状态	场景	EMS Builder 归属内存平均	EMS Builder 归属内存 P95	整机实际内存平均	整机实际内存 P95	整机实际内存峰值
🟢	S1	484.14 MB	529.22 MB	726.92 MB（74.02%）	810.83 MB（82.57%）	825.71 MB（84.08%）
🟡	S2	567.86 MB	589.11 MB	788.52 MB（80.30%）	878.61 MB（89.47%）	900.03 MB（91.65%）
🟢	S2.5	562.11 MB	580.93 MB	785.65 MB（80.01%）	845.52 MB（86.10%）	918.53 MB（93.54%）
🔴	S3	573.27 MB	603.92 MB	843.22 MB（85.87%）	930.97 MB（94.80%）	938.00 MB（95.52%）
🔴	S3.5	560.39 MB	590.84 MB	838.25 MB（85.36%）	902.91 MB（91.95%）	937.29 MB（95.45%）
🔴	S6	549.24 MB	608.00 MB	827.91 MB（84.31%）	932.14 MB（94.92%）	939.57 MB（95.68%）

五服务归属内存包含 cgroup 归属的共享页与缓存，不等于物理内存净占用。整机实际内存更能反映设备剩余容量，因此场景判定使用整机实际内存。AFE-E620 仅有 982 MB 物理内存：基准场景 S1 的整机内存平均值已达 74.02%，说明操作系统与 Edge-EMS Builder 的常驻占用已接近设备容量的四分之三；S3 及以后整机内存 P95 超过 91%，剩余可用内存不足 90 MB，已处于内存压力区。不同场景的数据库初始状态和缓存热度会影响结果，不应只根据点位数量推断内存变化。

九、处理量结果

平均处理量以完整 2,000 秒有效区间为分母；达成率依据任务总数除以目标总数计算，避免工作簿显示值四舍五入造成偏差。

状态	场景	Trigger 总数	Trigger 平均 / 目标	Trigger 达成率	MQTT 总数	MQTT 平均 / 目标	MQTT 达成率
🟢	S1	20,000	10.00 / 10	100.00%	10,000	5.00 / 5	100.00%
🟡	S2	78,917	39.46 / 40	98.65%	19,752	9.88 / 10	98.76%
🟢	S2.5	79,924	39.96 / 40	99.91%	19,964	9.98 / 10	99.82%
🔴	S3	77,536	38.77 / 90	43.08%	17,860	8.93 / 20	44.65%
🔴	S3.5	157,134	78.57 / 90	87.30%	34,676	17.34 / 20	86.69%
🔴	S6	57,442	28.72 / 150	19.15%	11,508	5.75 / 30	19.18%

本报告以 99% 作为推荐运行场景的处理量参考线。S2 略低于该参考线；S3、S3.5 和 S6 的任务处理能力已明显不足，负载进入过载区后任务队列持续积压，实际完成量远低于目标。

十、Trigger 时延

以下分位数基于有效区间内全部 Trigger 任务记录，单位为毫秒。

状态	场景	平均	P50	P95	P99	单次最大
🟢	S1	15.57	12	18	30	10,237
🟡	S2	22.98	9	28	61	11,012
🟢	S2.5	17.28	9	25	40	10,999
🔴	S3	70.61	17	120	713.65	27,281
🔴	S3.5	76.65	13	58	170	53,472
🔴	S6	71.90	17	127	610.59	24,421

S2.5 及以下的常态分位数较低，但各场景均存在约 10～11 秒的极端单次长尾。过载场景的平均值被长尾显著拉高（例如 S3.5 平均值 76.65 ms 高于 P95 的 58 ms，P50 仅 13 ms），判断常态体验应优先参考 P50 / P95。长尾不会明显改变 P99，却可能影响个别控制或告警任务，仍需专项排查。

十一、MQTT 时延

以下分位数基于有效区间内全部 MQTT 任务记录，单位为毫秒。

状态	场景	平均	P50	P95	P99	单次最大
🟢	S1	49.65	49	52	56	440
🟡	S2	54.77	51	64	90	1,182
🟢	S2.5	51.80	52	56	64	402
🔴	S3	93.56	56	249.05	944.41	2,471
🔴	S3.5	109.53	55	95	242	53,373
🔴	S6	95.33	59	201	782	19,969

十二、场景判定

场景	判定	主要依据
S1	通过	基准负载下 Trigger / MQTT 达成率均为 100%，整机 CPU P95 为 26.83%；注意整机内存平均已达 74.02%。
S2	有条件通过	资源余量尚可（整机 CPU P95 为 52.01%），但 Trigger / MQTT 达成率 98.65% / 98.76% 略低于 99% 参考线，并出现 34 次采样超时。
S2.5	推荐	在 2,000 点/秒负载下，Trigger / MQTT 达成率 99.91% / 99.82%，P95 分别为 25 ms 和 56 ms，整机 CPU P95 为 45.54%，是达到参考线的最高负载场景。
S3	未通过	Trigger / MQTT 达成率仅 43.08% / 44.65%，MQTT P99 为 944.41 ms，整机 CPU P95 为 82.71%，内存 P95 为 94.80%，出现 617 次采样超时。
S3.5	未通过	变化存储较 S3 明显改善（CPU P95 降至 66.05%，Trigger P95 降至 58 ms），但达成率 87.30% / 86.69% 仍低于参考线，出现 96 次采样超时。
S6	不建议任何生产使用	达成率仅 19.15% / 19.18%，整机 CPU P95 为 88.33%，内存 P95 为 94.92%，出现 886 次采样超时，设备已严重过载。

十三、容量与部署建议

13.1 已验证推荐配置

数据采集配置量：2,000 点/秒；
聚合运算：20 个；
普通 Trigger：20 次/秒；
100 ms Trigger：2 个，即 20 次/秒；
Trigger 合计：40 次/秒；
MQTT：10 次/秒；
协作任务：2 次/秒；
Trigger 任务记录：保存；
数据存储：变化存储，数值不变时最迟 10 秒保存一次。

13.2 生产部署建议

长期运行建议在上述已测配置基础上保留约 20% 工程余量，并使用实际 Lua 脚本、消息体大小和数据库历史量进行上线前复测。
AFE-E620 内存基线偏高（基准场景 S1整机内存平均已超过 74%），建议对整机 CPU 设置 80% 预警，对整机内存设置 85% 预警、90% 严重告警，并持续观察 PostgreSQL 缓存和数据库增长；必要时评估降低 PostgreSQL 内存配额或扩充机型。
需要实时存储时可参考 S2 的结果，但该场景达成率略低于 99% 参考线；若不是业务强制要求，优先采用 S2.5 的变化存储策略。
S3（5,000 点/秒）及以上负载已超出 AFE-E620 的持续承载能力，即使启用变化存储（S3.5）也未通过；有此容量需求时应选用 AFE-E630。
S6 在 E620 上已严重过载，不具备压力预检的参考价值；如需过载保护验证，建议使用 S3 量级的负载短时执行。

十四、质量告警与待补充测试

采样超时：S1 出现 3 次，S2 出现 34 次，S2.5 出现 8 次，S3 出现 617 次，S3.5 出现 96 次，S6 出现 886 次。过载场景中监控本身无法按时完成采样，相关场景的资源数据可信度下降，判定以处理量与时延为主。
补录本轮测试的 CommBridge / Edge-EMS Builder / PostgreSQL 软件版本，完善环境信息。
完整执行 72 小时稳定性测试，记录进程重启、OOM、错误日志、内存斜率和数据库增长；E620 内存基线高，需重点观察是否存在内存缓慢爬升。
为采集点、Trigger、MQTT、协作任务分别增加成功、失败、超时和丢弃计数。
补充磁盘吞吐、I/O wait、PostgreSQL WAL / checkpoint、连接池和队列深度。
对 Trigger 的 10～11 秒单次长尾，以及 S3.5 中 Trigger 与 MQTT 同时出现约 53 秒极端值的现象，关联任务 ID、Lua 脚本、SQL、GC、I/O 和系统日志排查。
记录每个场景开始前的数据库大小、PostgreSQL 配置和缓存热度，增强跨场景内存结果的可比性。

十五、数据限制

点位数是测试配置量，不是逐点成功计数；现有数据无法独立证明每个采集点均成功写入。
场景的业务配置（聚合数、Trigger 构成、协作任务数）沿用测试手册定义，工作簿内未记录逐场景配置明细。
工作簿没有业务错误率、任务结果状态和正确率字段，处理量达标不等于业务正确率为 100%。
本轮各场景均为约 33 分 20 秒的短时测试，适合比较性能，不替代长期稳定性测试。
本轮软件版本未随工作簿记录，结果与版本的对应关系待补录后确认。
S2.5 是当前批次达到 99% 处理量参考线的最高负载已测配置；20% 工程余量是容量规划建议，不是独立实测结论。

其他型号请参阅：AFE-E630 测试报告。