EMS Builder Performance Test Report on AFE-E630

Report version: v1.3
Test date: 2026-07-29
Report date: 2026-07-30
Statistical scope: 2,002 samples per scenario; exclude the first and last, using only the 2,000 valid resource samples at sample_no=2–2001
Related manual: Edge-EMS Builder performance test manual

1. Performance overview

✅ Recommended AFE-E630 scenario: S3.5

Among the six scenarios tested in this batch, S3.5 provides the best balance of load capacity, task latency, and whole-device resource headroom. Use change-based storage, saving at least every 10 seconds when values are unchanged, with the following load as the currently validated recommended configuration.

📡

5,000 points/s
Configured acquisition load

🧮

30
Aggregations

⚡

90/s
Trigger target

☁️

20/s
MQTT task target

🤝

10/s
Coordination tasks

💾

Change-based storage
Save at least every 10 seconds

🧠

50.16% / 71.09%
Whole-device CPU average / P95

🗄️

40.49% / 41.41%
Whole-device memory average / P95

⏱️

56 ms
Trigger P95

📨

77 ms
MQTT P95

Each Trigger execution represents one device-control operation, one local alarm and MQTT alarm, and one aggregation-data write. Edge-EMS Builder allocates PostgreSQL resources according to device memory, so memory usage may differ substantially across devices, database sizes, and cache states.

1.1 Key conclusion

Run AFE-E630 with scenario S3.5: 5,000 points/second, 30 aggregations, 90 Trigger tasks/second, 20 MQTT tasks/second, and 10 coordination tasks/second, with 10-second change-based storage.

S3.5 measured 89.97 Trigger tasks/second and 19.98 MQTT tasks/second. Trigger / MQTT P95 was 56 ms / 77 ms. Whole-device CPU P95 was 71.09%, actual whole-device memory P95 was 41.41%, and no sampling timeouts occurred.

For long-term production, reserve approximately 20% engineering headroom below the measured S3.5 load. Initial capacity can be planned at no more than approximately 4,000 points/second, 72 Trigger tasks/second, 16 MQTT tasks/second, and 8 coordination tasks/second. These are engineering estimates scaled from measured configuration, not separately tested scenarios. Retest with actual project scripts, message sizes, and historical database volumes before deployment.

1.2 Scenario status

Icon	Scenario	Conclusion
🟢	S1	Baseline passed, with ample resource and task-latency headroom.
🟢	S2	Passed: stable at 2,000 points/second with real-time storage; one sampling timeout.
🟢	S2.5	Passed: change-based storage significantly reduces CPU pressure versus S2, with no sampling timeouts.
🟡	S3	Task metrics passed, but whole-device CPU P95 is 81.06%, near the continuous-operation boundary; two sampling timeouts.
🟢	S3.5	Best overall performance; the currently recommended AFE-E630 scenario.
🔴	S6	Suitable only for a short stress precheck: CPU P95 is 94.02%, MQTT throughput is below the 99% guideline, and 11 sampling timeouts occurred.

2. Summary of findings

• This batch tested six scenarios: S1, S2, S2.5, S3, S3.5, and S6. Other scenarios are excluded from tables, comparisons, and conclusions.
• At a configured 5,000 points/second, S3.5 achieved 99.97% Trigger and 99.90% MQTT attainment, with P95 latency of 56 ms and 77 ms respectively.
• S3 and S3.5 have identical business loads. Change-based storage reduced average whole-device CPU from 57.95% to 50.16% and P95 from 81.06% to 71.09%, making S3.5 more suitable for continuous operation.
• S6 achieved 99.49% Trigger but 98.73% MQTT attainment. Whole-device CPU P95 reached 94.02%, with a 100% peak; continuous production use is not recommended.
• Overall Trigger P99 remained below 200 ms in all scenarios, but individual long-tail executions of roughly 10–12 seconds occurred. S6 MQTT P99 was 236.62 ms, exceeding 200 ms.
• Each scenario retained only 2,000 seconds, approximately 33 minutes 20 seconds, of valid samples. These support performance comparison, not a substitute for 72-hour stability testing.

3. Statistical methodology

3.1 Sample selection

Monitoring uses sample counts. Every scenario’s raw resource data contains sample_no=1–2002:

Exclude: sample_no = 1
Analyze: sample_no = 2–2001, 2,000 samples
Exclude: sample_no = 2002

Discarding boundary samples excludes incomplete initial and final seconds. Overall Trigger and MQTT results use 2,000 seconds as the denominator, including seconds without task records, to avoid overstating throughput by counting only populated seconds.

3.2 Complete EMS Builder scope

The following five services together constitute the complete Edge-EMS Builder:

Service	Purpose
cb_core	Data acquisition and core communication
cb_nginx	CommBridge Web / reverse proxy
cb_backend	CommBridge backend
ems_backend	EMS Builder computation, strategies, and business logic
ems_postgresql	EMS Builder data storage

Sum the five services at each sample_no, then compute average, P95, P99, and peak from the 2,000 totals. Do not add independent service peaks occurring at different times.

3.3 CPU, memory, and task latency

• Raw five-service CPU values use single-core-equivalent percentages. AFE-E630 has four cores, so Edge-EMS Builder four-core-equivalent CPU = sum of the five services ÷ 4.
• Whole-device CPU uses workbook _system_total, normalized to 0–100% of total CPU capacity. This is the primary capacity metric.
• Edge-EMS Builder attributed memory sums memory attributed to the five service cgroups. Shared pages and caches may be attributed more than once, so this can exceed actual whole-device used memory. Do not divide it directly by physical RAM to obtain capacity utilization.
• Actual whole-device memory is MemTotal - MemAvailable, the primary metric for physical-memory headroom.
• Trigger / MQTT average, P50, P95, and P99 use all task records in the valid interval, not percentiles of per-second averages.
• Every workbook passed the check that test load was stopped before summarization: Trigger, MQTT, and CommBridge were stopped, followed by a 30-second wait.

4. Device and test environment

Item	Configuration
Device model	AFE-E630
CPU	Arm Cortex-A55, 4 cores
Memory	3.81 GB DDR4
Operating system	JelinaOS, based on Debian 11
Storage	eMMC
Software versions	CommBridge-rc-2026-07-08T17-52-07; EMS Builder v1.2; PostgreSQL v18.3
Network	LAN; MQTT / TCP
Monitoring samples	Once per second; 2,002 samples per scenario, using the middle 2,000
Test data sources	perf_S1_20260729_171807.xlsx、perf_S2_20260729_175426.xlsx、perf_S2.5_20260729_183152.xlsx、perf_S3_20260729_190918.xlsx、perf_S3.5_20260729_194703.xlsx、perf_S6_20260729_202445.xlsx

5. Scenarios and loads

Scenario	Data acquisition	Aggregations	Regular Trigger	100 ms Trigger	Trigger target	MQTT target	Coordination tasks	Storage policy
S1	500 points/s	10	10/s	0	10/s	5/s	0/s	Real-time
S2	2,000 points/s	20	20/s	2	40/s	10/s	2/s	Real-time
S2.5	2,000 points/s	20	20/s	2	40/s	10/s	2/s	Change-based (10 seconds)
S3	5,000 points/s	30	50/s	4	90/s	20/s	10/s	Real-time
S3.5	5,000 points/s	30	50/s	4	90/s	20/s	10/s	Change-based (10 seconds)
S6	5,000 points/s	20	50/s	10	150/s	30/s	15/s	Real-time

Acquisition figures are configured scenario loads. The workbooks contain no per-point success counts, so configured values cannot be described as independently verified successful database-ingestion throughput.

6. Test periods

Scenario	Effective statistical interval	Effective duration
S1	2026-07-29 17:18:09 – 17:51:29	2,000 seconds
S2	2026-07-29 17:54:29 – 18:27:49	2,000 seconds
S2.5	2026-07-29 18:31:54 – 19:05:14	2,000 seconds
S3	2026-07-29 19:09:20 – 19:42:40	2,000 seconds
S3.5	2026-07-29 19:47:06 – 20:20:26	2,000 seconds
S6	2026-07-29 20:24:47 – 20:58:07	2,000 seconds

All times are UTC+8.

7. CPU results

7.1 EMS Builder five-service total: four-core equivalent

Status	Scenario	Average	P95	P99	Peak
🟢	S1	13.48%	23.97%	41.50%	62.53%
🟢	S2	28.47%	48.33%	56.36%	67.17%
🟢	S2.5	26.11%	38.36%	49.96%	65.76%
🟡	S3	50.58%	72.31%	78.55%	95.43%
🟢	S3.5	43.50%	61.27%	70.93%	86.75%
🔴	S6	65.95%	85.87%	91.61%	208.59%

The S6 Edge-EMS Builder peak of 208.59% is an anomalous single sampling window, with combined CPU time exceeding ordinary four-core capacity. Together with 11 sampling timeouts, this suggests a sampling window spanning intervals or burst scheduling. It is not treated as sustainable resource usage.

7.2 Whole-device CPU: normalized to total capacity

Status	Scenario	Average	P95	P99	Peak
🟢	S1	20.22%	38.67%	48.57%	67.70%
🟢	S2	35.88%	57.58%	66.41%	82.42%
🟢	S2.5	32.72%	45.28%	57.03%	75.06%
🟡	S3	57.95%	81.06%	89.16%	98.64%
🟢	S3.5	50.16%	71.09%	79.84%	96.98%
🔴	S6	73.86%	94.02%	97.95%	100.00%

Whole-device CPU is the main basis for evaluating CPU capacity. S3.5 P95 is 9.97 percentage points below S3. S6 P95 exceeds 90%, leaving insufficient continuous-operation headroom.

8. Memory results

Status	Scenario	EMS Builder attributed memory average	EMS Builder attributed memory P95	Actual whole-device memory average	Actual whole-device memory P95	Actual whole-device memory peak
🟢	S1	2,666.77 MB	2,704.44 MB	1,550.46 MB (39.74%)	1,637.29 MB (41.97%)	1,694.09 MB (43.42%)
🟢	S2	2,805.86 MB	2,895.39 MB	1,579.23 MB (40.48%)	1,675.40 MB (42.94%)	1,736.57 MB (44.51%)
🟢	S2.5	2,881.41 MB	2,933.45 MB	1,507.67 MB (38.64%)	1,596.94 MB (40.93%)	1,667.61 MB (42.74%)
🟡	S3	3,067.36 MB	3,119.55 MB	1,591.41 MB (40.79%)	1,684.10 MB (43.17%)	1,759.92 MB (45.11%)
🟢	S3.5	3,059.29 MB	3,106.37 MB	1,579.83 MB (40.49%)	1,615.76 MB (41.41%)	1,702.34 MB (43.63%)
🔴	S6	3,071.13 MB	3,123.09 MB	1,636.22 MB (41.94%)	1,721.25 MB (44.12%)	1,791.94 MB (45.93%)

Attributed memory includes cgroup-attributed shared pages and caches and is not net physical-memory usage. Actual whole-device memory better reflects remaining capacity and is used for scenario assessment. Initial database state and cache warmth affect results; do not infer memory changes from point counts alone.

9. Throughput results

Average throughput uses the full 2,000-second valid interval. Attainment is total tasks divided by target total tasks, avoiding rounding bias from workbook display values.

Status	Scenario	Trigger total	Trigger average / target	Trigger attainment	MQTT total	MQTT average / target	MQTT attainment
🟢	S1	20,000	10.00 / 10	100.00%	10,000	5.00 / 5	100.00%
🟢	S2	79,990	40.00 / 40	99.99%	19,995	10.00 / 10	99.98%
🟢	S2.5	79,990	40.00 / 40	99.99%	20,000	10.00 / 10	100.00%
🟡	S3	179,788	89.89 / 90	99.88%	39,800	19.90 / 20	99.50%
🟢	S3.5	179,943	89.97 / 90	99.97%	39,960	19.98 / 20	99.90%
🔴	S6	298,469	149.23 / 150	99.49%	59,239	29.62 / 30	98.73%

This report uses 99% as the throughput guideline for recommended operating scenarios. S6 MQTT falls below it, alongside high CPU, rising latency, and sampling timeouts, indicating operation in the stress region.

10. Trigger latency

Percentiles below use all Trigger task records in the valid interval, in milliseconds.

Status	Scenario	Average	P50	P95	P99	Maximum individual duration
🟢	S1	47.86	19	32	47	10,160
🟢	S2	23.65	11	30	53	10,938
🟢	S2.5	26.06	17	46	69	10,938
🟡	S3	37.69	14	55	99	10,993
🟢	S3.5	29.88	15	56	88	10,994
🔴	S6	44.06	17	87	162	11,985

Typical percentiles are low, but every scenario has extreme individual long-tail executions of roughly 10–12 seconds. These may not materially change P99 but can affect individual control or alarm tasks and require dedicated investigation.

11. MQTT latency

Percentiles below use all MQTT task records in the valid interval, in milliseconds.

Status	Scenario	Average	P50	P95	P99	Maximum individual duration
🟢	S1	57.90	57	65	73	122
🟢	S2	57.83	57	67	76	115
🟢	S2.5	57.13	56	65	74	330
🟡	S3	62.31	58	89	146	340
🟢	S3.5	58.60	57	77	98	220
🔴	S6	74.79	64	134	236.62	920

12. Scenario assessment

Scenario	Assessment	Main basis
S1	Passed	At baseline load, whole-device CPU P95 is 38.67%, memory P95 41.97%, and task throughput meets targets.
S2	Passed	Trigger and MQTT attainment approach 100%, with ample resource headroom; monitor the one sampling timeout.
S2.5	Passed	Throughput meets targets; change-based storage reduces both average CPU and P95 substantially versus S2.
S3	Conditionally passed	Throughput and latency meet targets, but CPU P95 is 81.06%, with two sampling timeouts and limited continuous-operation headroom.
S3.5	Recommended	At 5,000 points/second, Trigger / MQTT P95 remain below 100 ms; CPU P95 is 71.09%, actual memory P95 41.41%, with no sampling timeouts.
S6	Not recommended for continuous operation	MQTT attainment is 98.73%, P99 236.62 ms, CPU P95 94.02%, with 11 sampling timeouts.

13. Capacity and deployment recommendations

13.1 Validated recommended configuration

• Configured acquisition load: 5,000 points/second.
• Aggregations: 30.
• Regular Trigger: 50/second.
• 100 ms Trigger: 4, equivalent to 40/second.
• Total Trigger: 90/second.
• MQTT: 20/second.
• Coordination tasks: 10/second.
• Trigger task records: retained.
• Storage: change-based, saving at least every 10 seconds when values are unchanged.

13.2 Production deployment recommendations

• Reserve approximately 20% engineering headroom below the tested configuration for long-term operation, and retest with actual Lua scripts, message sizes, and historical database volumes before deployment.
• Set whole-device CPU warnings at 80%, memory warnings at 70%, and critical memory alarms at 80%. Continuously monitor PostgreSQL cache and database growth.
• For real-time storage, refer to S3, but its whole-device CPU P95 exceeds 80%. Prefer S3.5 change-based storage unless business requirements mandate real-time storage.
• Use S6 only for short stress, rate-limiting, or overload-protection validation, not sustained E630 production load.

14. Quality warnings and further tests

1. Sampling timeouts: one in S2, two in S3, and 11 in S6; none found in S1, S2.5, or S3.5.
2. Complete 72-hour stability testing, recording process restarts, OOM events, error logs, memory growth rate, and database growth.
3. Add separate success, failure, timeout, and discard counts for acquisition points, Trigger, MQTT, and coordination tasks.
4. Add disk throughput, I/O wait, PostgreSQL WAL/checkpoint, connection-pool, and queue-depth metrics.
5. Correlate Trigger’s 10–12-second individual long tails with task IDs, Lua scripts, SQL, GC, I/O, and system logs.
6. Record database size, PostgreSQL configuration, and cache warmth before each scenario to improve comparability of memory results.

15. Data limitations

• Point counts are configured loads, not per-point success counts; existing data cannot independently prove every point was stored successfully.
• Workbooks lack business error rates, task-result states, and correctness fields. Meeting throughput targets does not imply 100% business correctness.
• All scenarios are short tests of approximately 33 minutes 20 seconds, suitable for comparison, not long-term stability validation.
• S3.5 is the best overall measured configuration in this batch. The 20% headroom is capacity-planning advice, not an independently measured conclusion.

For the other model, see the AFE-E620 test report.