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 測試報告。