EMS Builder Performance Test Report on AFE-E620

Report version: v1.0
Test date: 2026-07-30 – 2026-07-31
Report date: 2026-07-31
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-E620 scenario: S2.5

Among the six scenarios tested, S2.5 is the highest load reaching the 99% task-attainment guideline. AFE-E620 has only 982 MB RAM, and whole-device memory usage is high in all scenarios, making memory the main capacity constraint. Use change-based storage, saving at least every 10 seconds when values are unchanged, with the following load as the currently validated recommended configuration.

📡

2,000 points/s
Configured acquisition load

🧮

20
Aggregations

⚡

40/s
Trigger target

☁️

10/s
MQTT task target

🤝

2/s
Coordination tasks

💾

Change-based storage
Save at least every 10 seconds

🧠

26.24% / 45.54%
Whole-device CPU average / P95

🗄️

80.01% / 86.10%
Whole-device memory average / P95

⏱️

25 ms
Trigger P95

📨

56 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 usage can differ substantially across devices, database sizes, and cache states. AFE-E620 has only 982 MB physical RAM, substantially less headroom than AFE-E630. Prioritize memory when planning capacity.

1.1 Key conclusion

Run AFE-E620 with scenario S2.5: 2,000 points/second, 20 aggregations, 40 Trigger tasks/second, 10 MQTT tasks/second, and 2 coordination tasks/second, with 10-second change-based storage.

S2.5 measured 39.96 Trigger tasks/second and 9.98 MQTT tasks/second, attaining 99.91% and 99.82% respectively. Trigger / MQTT P95 was 25 ms / 56 ms. Whole-device CPU P95 was 45.54%, actual whole-device memory P95 86.10%, with eight sampling timeouts.

For long-term production, reserve approximately 20% engineering headroom below the measured S2.5 load. Plan initial capacity at no more than approximately 1,600 points/second, 32 Trigger tasks/second, 8 MQTT tasks/second, and 2 coordination tasks/second. These are engineering estimates scaled from measured configuration, not separately tested scenarios. Retest actual project scripts, message sizes, and historical database volumes before deployment.

1.2 Scenario status

Icon	Scenario	Conclusion
🟢	S1	Baseline passed with 100% attainment, but average whole-device memory is already 74.02%, a high baseline.
🟡	S2	With real-time storage, Trigger / MQTT attainment is 98.65% / 98.76%, slightly below the 99% guideline; 34 sampling timeouts.
🟢	S2.5	Highest load reaching the 99% guideline; the currently recommended AFE-E620 scenario.
🔴	S3	Failed: Trigger / MQTT attainment is only 43.08% / 44.65%, latency deteriorates substantially, and 617 sampling timeouts occur.
🔴	S3.5	Failed: change-based storage significantly improves S3, but attainment remains 87.30% / 86.69%, below 99%.
🔴	S6	Severe overload: Trigger / MQTT attainment is only 19.15% / 19.18%, with 886 sampling timeouts.

2. Summary of findings

This batch tested S1, S2, S2.5, S3, S3.5, and S6. Other scenarios are excluded from tables, comparisons, and conclusions.
At a configured 2,000 points/second, S2.5 achieved 99.91% Trigger and 99.82% MQTT attainment, with P95 latency of 25 ms and 56 ms respectively.
S2 and S2.5 have identical business loads. Change-based storage reduced average whole-device CPU from 29.41% to 26.24% and P95 from 52.01% to 45.54%, while raising Trigger attainment from 98.65% to 99.91%.
S3 and S3.5 have identical business loads. Change-based storage increased Trigger attainment from 43.08% to 87.30% and MQTT from 44.65% to 86.69%, reducing CPU P95 from 82.71% to 66.05%, but still failed. A load of 5,000 points/second exceeds AFE-E620’s sustained capacity.
Compared with AFE-E630: E630 supports S3.5, with 5,000 points/second and 90 Trigger tasks/second; E620’s validated limit is S2.5, with 2,000 points/second and 40 Trigger tasks/second. The memory gap, 3.81 GB versus 982 MB, is the main source of the difference.
Individual Trigger long tails of approximately 10–11 seconds occur in every scenario and worsen under overload. S3.5 maximum individual durations reach 53,472 ms for Trigger and 53,373 ms for MQTT.
Average whole-device memory exceeds 74% in all scenarios, and P95 exceeds 91% from S3 onward. Memory is E620’s common bottleneck and requires continuous monitoring.
Each scenario retained only 2,000 seconds, approximately 33 minutes 20 seconds, of valid samples. These support 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-E620 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. Memory percentages in this report use MemTotal = 982 MB.
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-E620
CPU	Arm Cortex-A55, 4 cores
Memory	982 MB DDR3
Operating system	JelinaOS, based on Ubuntu 20.04
Storage	eMMC
Software versions	To be supplied: this batch’s workbooks did not record versions; add CommBridge / EMS Builder / PostgreSQL versions before archiving
Network	LAN; MQTT / TCP
Monitoring samples	Once per second; 2,002 samples per scenario, using the middle 2,000
Test data sources	`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`

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, with scenario definitions inherited from the test manual. Workbooks contain neither per-point success counts nor detailed per-scenario configuration, so configured values cannot be described as independently verified successful database-ingestion throughput. Trigger / MQTT targets match the workbooks’ attainment-validation targets.

6. Test periods

Scenario	Effective statistical interval	Effective duration
S1	2026-07-30 10:13:55 – 10:47:13	2,000 seconds
S2	2026-07-30 10:51:30 – 11:24:48	2,000 seconds
S2.5	2026-07-30 11:30:33 – 12:03:51	2,000 seconds
S3	2026-07-30 15:25:51 – 15:59:09	2,000 seconds
S3.5	2026-07-31 12:23:59 – 12:57:17	2,000 seconds
S6	2026-07-31 17:36:29 – 18:09:47	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	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%

Edge-EMS Builder peaks in S2, S3, and S3.5 are 110.22%, 115.84%, and 130.65% respectively. These instantaneous single-window values imply combined CPU time above ordinary four-core capacity; for example, one S2 ems_backend sample reaches 402%. Together with sampling timeouts, this suggests windows spanning intervals or burst scheduling. These values are not treated as sustainable resource usage.

7.2 Whole-device CPU: normalized to total capacity

Status	Scenario	Average	P95	P99	Peak
🟢	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%

Whole-device CPU is the main basis for evaluating CPU capacity. S2.5 P95 is 6.47 percentage points below S2. From S3 onward, P95 exceeds 66% and peaks reach 100%, indicating CPU saturation.

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	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%)

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. AFE-E620 has only 982 MB physical RAM: S1 baseline average memory already reaches 74.02%, meaning the resident operating system and Edge-EMS Builder occupy nearly three quarters of capacity. From S3 onward, whole-device memory P95 exceeds 91%, leaving less than 90 MB available and indicating memory pressure. 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	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%

This report uses 99% as the throughput guideline for recommended operating scenarios. S2 falls slightly below it. S3, S3.5, and S6 clearly lack sufficient processing capacity: task queues continue to accumulate under overload and actual completions fall far below targets.

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	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

Typical percentiles are low at S2.5 and below, but every scenario has extreme individual long tails of approximately 10–11 seconds. Under overload, long tails substantially inflate averages; for example, S3.5 averages 76.65 ms, above its P95 of 58 ms, while P50 is only 13 ms. Use P50 / P95 to assess typical experience. Long tails 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	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

12. Scenario assessment

Scenario	Assessment	Main basis
S1	Passed	Trigger / MQTT both attain 100% at baseline; CPU P95 is 26.83%. Note average whole-device memory already at 74.02%.
S2	Conditionally passed	Resource headroom remains acceptable, with CPU P95 at 52.01%, but Trigger / MQTT attainment of 98.65% / 98.76% is slightly below 99%, with 34 sampling timeouts.
S2.5	Recommended	At 2,000 points/second, Trigger / MQTT attainment is 99.91% / 99.82%, P95 is 25 ms / 56 ms, and CPU P95 is 45.54%: the highest load meeting the guideline.
S3	Failed	Trigger / MQTT attainment is only 43.08% / 44.65%; MQTT P99 is 944.41 ms, CPU P95 82.71%, memory P95 94.80%, with 617 sampling timeouts.
S3.5	Failed	Change-based storage improves S3 substantially, reducing CPU P95 to 66.05% and Trigger P95 to 58 ms, but attainment remains below the guideline at 87.30% / 86.69%, with 96 sampling timeouts.
S6	Not recommended for any production use	Attainment is only 19.15% / 19.18%, CPU P95 88.33%, memory P95 94.92%, with 886 sampling timeouts: severe overload.

13. Capacity and deployment recommendations

13.1 Validated recommended configuration

Configured acquisition load: 2,000 points/second.
Aggregations: 20.
Regular Trigger: 20/second.
100 ms Trigger: 2, equivalent to 20/second.
Total Trigger: 40/second.
MQTT: 10/second.
Coordination tasks: 2/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 measured configuration for long-term operation. Retest actual Lua scripts, message sizes, and historical database volumes before deployment.
AFE-E620 has a high memory baseline: whole-device average memory exceeds 74% even in baseline scenario S1. Set CPU warnings at 80%, memory warnings at 85%, and critical memory alarms at 90%. Continuously monitor PostgreSQL cache and database growth; consider reducing PostgreSQL memory allocation or selecting a higher-capacity model when needed.
For real-time storage, refer to S2, but its attainment is slightly below 99%. Prefer S2.5 change-based storage unless business requirements mandate otherwise.
S3, at 5,000 points/second, and higher loads exceed sustained AFE-E620 capacity, even with change-based storage in S3.5. Choose AFE-E630 for this capacity requirement.
S6 severely overloads E620 and is not useful as a stress-precheck reference. For overload-protection validation, briefly apply a load around S3 instead.

14. Quality warnings and further tests

Sampling timeouts: S1 had 3, S2 34, S2.5 8, S3 617, S3.5 96, and S6 886. Under overload, monitoring itself fails to sample on time, reducing resource-data reliability. Base assessment primarily on throughput and latency.
Add the CommBridge / Edge-EMS Builder / PostgreSQL versions used in this batch to complete environment information.
Complete 72-hour stability testing, recording restarts, OOM events, error logs, memory growth rate, and database growth. E620’s high memory baseline makes slow memory growth especially important to monitor.
Add separate success, failure, timeout, and discard counts for acquisition points, Trigger, MQTT, and coordination tasks.
Add disk throughput, I/O wait, PostgreSQL WAL/checkpoint, connection-pool, and queue-depth metrics.
Investigate 10–11-second individual Trigger long tails and simultaneous approximately 53-second Trigger/MQTT extremes in S3.5 by correlating task IDs, Lua scripts, SQL, GC, I/O, and system logs.
Record database size, PostgreSQL configuration, and cache warmth before every scenario to improve memory-result comparability.

15. Data limitations

Point counts are configured loads, not per-point success counts; existing data cannot independently prove every point was written successfully.
Business configurations, including aggregation counts, Trigger composition, and coordination-task counts, follow the test manual. Workbooks lack detailed per-scenario configuration.
Workbooks lack business error rates, task-result states, and correctness fields. Throughput attainment 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.
Software versions were not recorded with the workbooks; the relationship between results and versions remains to be confirmed after this information is added.
S2.5 is the highest measured load in this batch meeting the 99% throughput guideline. The 20% headroom is capacity-planning advice, not an independently measured conclusion.

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