Informe de rendimiento de EMS Builder en AFE-E620

Versión del informe: v1.0
Fecha de prueba: 2026-07-30 ～ 2026-07-31
Fecha del informe: 2026-07-31
Metodología: 2.002 muestras por escenario, excluyendo la primera y la última; solo se analizan las 2.000 muestras válidas de recursos con sample_no=2～2001.
Manual relacionado: Pruebas de rendimiento de Edge-EMS Builder

1. Resumen de resultados de rendimiento

✅ Escenario recomendado para AFE-E620: S2.5

Entre los seis escenarios medidos, S2.5 es el de mayor carga que alcanza el 99% de cumplimiento de referencia. AFE-E620 solo dispone de 982 MB de memoria y su ocupación es alta en todos los escenarios; la memoria es la principal restricción de capacidad. Se recomienda almacenamiento por cambios, guardando como máximo cada 10 segundos si el valor permanece igual, con la siguiente configuración validada.

📡

2.000 puntos/s
Carga de adquisición configurada

🧮

20
Agregaciones

⚡

40/s
Objetivo Trigger

☁️

10/s
Objetivo de tareas MQTT

🤝

2/s
Tareas de coordinación

💾

Por cambios
Guardado cada 10 s como máximo

🧠

26,24% / 45,54%
CPU del equipo: media / P95

🗄️

80,01% / 86,10%
Memoria del equipo: media / P95

⏱️

25 ms
Trigger P95

📨

56 ms
MQTT P95

Cada ejecución de Trigger representa una operación de control de dispositivo, una alarma local y una alarma MQTT, y una escritura agregada. Edge-EMS Builder asigna recursos a PostgreSQL según la memoria del equipo; el consumo puede variar considerablemente entre dispositivos, tamaños de base de datos y estados de caché. AFE-E620 solo tiene 982 MB de memoria física, con mucho menos margen que AFE-E630; la planificación debe priorizar la memoria.

1.1 Conclusión principal

Se recomienda ejecutar AFE-E620 con S2.5: 2.000 puntos/s, 20 agregaciones, 40 Trigger/s, 10 tareas MQTT/s y 2 tareas de coordinación/s, con almacenamiento por cambios de 10 segundos.

S2.5 procesó 39,96 Trigger/s y 9,98 MQTT/s, con cumplimiento de 99,91% y 99,82%. Los P95 fueron 25 ms y 56 ms. La CPU P95 del equipo fue 45,54% y la memoria real P95, 86,10%. Hubo ocho tiempos de espera de muestreo agotados.

Para producción prolongada, reserva aproximadamente un 20% de margen de ingeniería respecto a S2.5. La planificación inicial puede limitarse a aproximadamente 1.600 puntos/s, 32 Trigger/s, 8 MQTT/s y 2 tareas de coordinación/s. Es una recomendación derivada de la configuración medida, no un escenario ensayado por separado. Repite las pruebas con scripts, tamaños de mensaje y volumen histórico reales antes de producción.

1.2 Estado de cada escenario

Icono	Escenario	Conclusión
🟢	S1	Escenario base superado, con cumplimiento del 100%; la memoria media del equipo ya alcanza 74,02%, una base elevada.
🟡	S2	Con almacenamiento en tiempo real, Trigger / MQTT alcanzan 98,65% / 98,76%, ligeramente por debajo del 99% de referencia; hubo 34 tiempos de espera de muestreo agotados.
🟢	S2.5	Escenario de mayor carga que alcanza el 99% de referencia; recomendado actualmente para AFE-E620.
🔴	S3	No superado: cumplimiento de Trigger / MQTT de solo 43,08% / 44,65%, latencia muy deteriorada y 617 tiempos de espera de muestreo agotados.
🔴	S3.5	No superado: el almacenamiento por cambios mejora claramente S3, pero el cumplimiento de 87,30% / 86,69% sigue por debajo del 99%.
🔴	S6	Sobrecarga grave: cumplimiento de Trigger / MQTT de solo 19,15% / 19,18% y 886 tiempos de espera de muestreo agotados.

2. Síntesis de conclusiones

Se probaron S1, S2, S2.5, S3, S3.5 y S6. Los demás escenarios no se incluyen en tablas, comparaciones ni conclusiones.
Con 2.000 puntos/s configurados, S2.5 alcanzó 99,91% en Trigger y 99,82% en MQTT; los P95 fueron 25 ms y 56 ms.
S2 y S2.5 tienen la misma carga funcional. El almacenamiento por cambios redujo la CPU media de 29,41% a 26,24% y P95 de 52,01% a 45,54%, y elevó el cumplimiento Trigger de 98,65% a 99,91%.
S3 y S3.5 tienen la misma carga funcional. El almacenamiento por cambios elevó el cumplimiento Trigger de 43,08% a 87,30% y MQTT de 44,65% a 86,69%, y redujo CPU P95 de 82,71% a 66,05%. Aun así, no se superó la prueba: 5.000 puntos/s exceden la capacidad continua de AFE-E620.
AFE-E630 admite S3.5, con 5.000 puntos/s y 90 Trigger/s; el límite validado de E620 es S2.5, con 2.000 puntos/s y 40 Trigger/s. La diferencia de memoria, 3,81 GB frente a 982 MB, es el principal factor diferenciador.
Todos los escenarios presentan ejecuciones Trigger de unos 10–11 segundos. En sobrecarga se agravan: S3.5 alcanza máximos individuales de 53.472 ms en Trigger y 53.373 ms en MQTT.
La memoria media del equipo supera 74% en todos los escenarios, y P95 supera 91% desde S3. La memoria es un cuello de botella común de E620 que requiere supervisión continua.
Cada escenario conserva únicamente 2.000 segundos válidos, unos 33 minutos y 20 segundos. Sirven para comparar rendimiento, no para sustituir 72 horas de estabilidad.

3. Metodología estadística

3.1 Selección de muestras

La supervisión utiliza un recuento fijo. Los datos originales de recursos de cada escenario incluyen sample_no=1～2002:

Excluir: sample_no = 1
Analizar: sample_no = 2–2001, 2,000 muestras
Excluir: sample_no = 2002

Excluir los extremos evita incluir segundos incompletos al iniciar y terminar. Los resultados globales de Trigger y MQTT utilizan 2.000 segundos como denominador. Los segundos sin tareas también cuentan en la media, evitando sobreestimar el rendimiento al considerar solo los que tienen registros.

3.2 Alcance completo de EMS Builder

Estos cinco servicios se consideran conjuntamente un Edge-EMS Builder completo:

Servicio	Función
`cb_core`	Adquisición de datos y comunicaciones principales
`cb_nginx`	Web de CommBridge / proxy inverso
`cb_backend`	Backend de CommBridge
`ems_backend`	Cálculos, estrategias y lógica de negocio de EMS Builder
`ems_postgresql`	Almacenamiento de datos de EMS Builder

Primero se suman los cinco servicios para cada sample_no. Después se calculan media, P95, P99 y máximo sobre los 2.000 totales. No se suman máximos independientes ocurridos en momentos distintos.

3.3 CPU, memoria y latencia de tareas

La CPU original de los cinco servicios se expresa como porcentaje equivalente de un núcleo. AFE-E620 tiene cuatro núcleos: «CPU equivalente de EMS Builder sobre cuatro núcleos» = suma de los cinco servicios ÷ 4.
«CPU del equipo» utiliza _system_total del libro, normalizado entre 0 y 100% de la capacidad total. Es el principal indicador de capacidad del dispositivo.
«Memoria atribuida a Edge-EMS Builder» suma la memoria atribuida por cgroup a los cinco servicios. Páginas compartidas y cachés pueden contabilizarse varias veces; puede superar la memoria real del equipo y no debe dividirse directamente por la memoria física para expresar ocupación.
«Memoria real del equipo» se calcula como MemTotal - MemAvailable y es la referencia principal para evaluar el margen de memoria física. Los porcentajes de este informe utilizan MemTotal = 982 MB.
Las medias y P50, P95 y P99 de Trigger / MQTT se calculan sobre todas las tareas del intervalo válido, no sobre medias por segundo.
Todos los libros superaron la comprobación de cierre de carga antes del resumen: Trigger, MQTT y CommBridge se detuvieron y se esperaron 30 segundos antes de resumir.

4. Equipo y entorno de prueba

Elemento	Configuración
Modelo de equipo	AFE-E620
CPU	Arm Cortex-A55, 4 núcleos
Memoria	982 MB DDR3
Sistema operativo	JelinaOS, basado en Ubuntu 20,04
Almacenamiento	eMMC
Versión de software	Pendiente: los libros no registran las versiones; completar CommBridge / EMS Builder / PostgreSQL antes de archivar
Red	Red local; MQTT / TCP
Muestreo de supervisión	Una muestra por segundo; 2.002 por escenario, analizando las 2.000 intermedias
Fuentes de datos de prueba	`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. Escenarios y cargas

Escenario	Adquisición	Agregaciones	Trigger normales	100 ms Trigger	Objetivo Trigger	Objetivo MQTT	Tareas de coordinación	Política de almacenamiento
S1	500 puntos/s	10	10/s	0	10/s	5/s	0/s	Tiempo real
S2	2.000 puntos/s	20	20/s	2	40/s	10/s	2/s	Tiempo real
S2.5	2.000 puntos/s	20	20/s	2	40/s	10/s	2/s	Por cambios (10 s)
S3	5.000 puntos/s	30	50/s	4	90/s	20/s	10/s	Tiempo real
S3.5	5.000 puntos/s	30	50/s	4	90/s	20/s	10/s	Por cambios (10 s)
S6	5.000 puntos/s	20	50/s	10	150/s	30/s	15/s	Tiempo real

La adquisición representa la carga configurada según los escenarios del manual. Los libros no incluyen recuentos de éxito por punto ni detalles de configuración por escenario; no puede presentarse como un caudal de inserción correcta validado independientemente. Los objetivos Trigger / MQTT coinciden con los utilizados para validar cumplimiento en los libros.

6. Horarios de prueba

Escenario	Intervalo estadístico válido	Duración válida
S1	2026-07-30 10:13:55 ～ 10:47:13	2.000 s
S2	2026-07-30 10:51:30 ～ 11:24:48	2.000 s
S2.5	2026-07-30 11:30:33 ～ 12:03:51	2.000 s
S3	2026-07-30 15:25:51 ～ 15:59:09	2.000 s
S3.5	2026-07-31 12:23:59 ～ 12:57:17	2.000 s
S6	2026-07-31 17:36:29 ～ 18:09:47	2.000 s

Todos los horarios están en UTC+8.

7. Resultados de CPU

7.1 Total de los cinco servicios de EMS Builder, equivalente a cuatro núcleos

Estado	Escenario	Media	P95	P99	Máximo
🟢	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%

Los máximos de EMS Builder en S2, S3 y S3.5 son 110,22%, 115,84% y 130,65%. Son valores instantáneos de una ventana de muestreo en los que el tiempo acumulado de los cinco servicios supera la capacidad habitual de cuatro núcleos; por ejemplo, ems_backend alcanza 402% en una muestra de S2. Junto con los tiempos de espera agotados, pueden indicar ventanas que abarcan periodos distintos o ráfagas de planificación. No se consideran consumos sostenibles.

7.2 CPU del equipo, normalizada a toda la capacidad

Estado	Escenario	Media	P95	P99	Máximo
🟢	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%

La CPU del equipo es la referencia principal de capacidad. S2.5 tiene un P95 6,47 puntos porcentuales inferior a S2. Desde S3, P95 supera 66% y los máximos alcanzan 100%; la CPU entra en saturación.

8. Resultados de memoria

Estado	Escenario	Memoria atribuida a EMS Builder: media	Memoria atribuida a EMS Builder: P95	Memoria real del equipo: media	Memoria real del equipo: P95	Memoria real del equipo: máximo
🟢	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%）

La memoria atribuida a los cinco servicios incluye páginas compartidas y cachés atribuidas por cgroup; no equivale al consumo físico neto. La memoria real refleja mejor el margen y se utiliza para evaluar escenarios. AFE-E620 solo tiene 982 MB físicos: S1 ya alcanza una media de 74,02%, de modo que el sistema operativo y los servicios residentes de Edge-EMS Builder consumen cerca de tres cuartas partes de la capacidad. Desde S3, la memoria P95 supera 91%, con menos de 90 MB disponibles y presión de memoria. El estado inicial de la base de datos y el calentamiento de cachés afectan al resultado; no deduzcas los cambios de memoria únicamente del número de puntos.

9. Volumen de procesamiento

Las medias utilizan los 2.000 segundos válidos completos. El cumplimiento se calcula dividiendo el total de tareas por el total objetivo, evitando desviaciones por redondeos de los valores mostrados en el libro.

Estado	Escenario	Total Trigger	Trigger: media / objetivo	Cumplimiento Trigger	Total MQTT	MQTT: media / objetivo	Cumplimiento 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%

La referencia para recomendar un escenario es 99%. S2 queda ligeramente por debajo; S3, S3.5 y S6 tienen una capacidad de tareas claramente insuficiente. En sobrecarga, las colas crecen de forma persistente y las tareas completadas quedan muy por debajo del objetivo.

10. Latencia de Trigger

Los percentiles siguientes utilizan todos los registros Trigger del intervalo válido. Unidad: milisegundos.

Estado	Escenario	Media	P50	P95	P99	Máximo individual
🟢	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

Los percentiles habituales son bajos hasta S2.5, pero todos los escenarios presentan ejecuciones extremas de unos 10–11 segundos. En sobrecarga, estas colas largas elevan notablemente las medias: en S3.5, la media de 76,65 ms supera P95 de 58 ms, mientras P50 es solo 13 ms. Utiliza preferentemente P50 / P95 para valorar el comportamiento habitual. Las colas largas apenas alteran P99, pero pueden afectar a controles o alarmas concretos y requieren investigación específica.

11. Latencia de MQTT

Los percentiles siguientes utilizan todos los registros MQTT del intervalo válido. Unidad: milisegundos.

Estado	Escenario	Media	P50	P95	P99	Máximo individual
🟢	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. Evaluación de escenarios

Escenario	Evaluación	Fundamento principal
S1	Superado	Con carga base, Trigger / MQTT alcanzan 100% y la CPU P95 del equipo es 26,83%; la memoria media ya alcanza 74,02%.
S2	Superado con condiciones	Existe cierto margen de recursos, con CPU P95 de 52,01%, pero Trigger / MQTT alcanzan 98,65% / 98,76%, por debajo del 99%; hubo 34 tiempos de espera de muestreo agotados.
S2.5	Recomendado	Con 2.000 puntos/s, Trigger / MQTT alcanzan 99,91% / 99,82%, sus P95 son 25 ms / 56 ms y la CPU P95 es 45,54%; es la mayor carga que alcanza la referencia.
S3	No superado	Trigger / MQTT solo alcanzan 43,08% / 44,65%; MQTT P99 es 944,41 ms, CPU P95 82,71%, memoria P95 94,80% y hubo 617 tiempos de espera de muestreo agotados.
S3.5	No superado	El almacenamiento por cambios mejora S3: CPU P95 baja a 66,05% y Trigger P95 a 58 ms. Sin embargo, el cumplimiento de 87,30% / 86,69% sigue bajo la referencia y hubo 96 tiempos de espera de muestreo agotados.
S6	No recomendado para ningún uso en producción	Cumplimiento de solo 19,15% / 19,18%, CPU P95 de 88,33%, memoria P95 de 94,92% y 886 tiempos de espera de muestreo agotados; sobrecarga grave.

13. Recomendaciones de capacidad y despliegue

13.1 Configuración recomendada validada

Adquisición configurada: 2.000 puntos/s.
Agregaciones: 20.
Trigger normales: 20/s.
Trigger de 100 ms: 2, equivalentes a 20/s.
Total Trigger: 40/s.
MQTT: 10/s.
Coordinación: 2 tareas/s.
Registros de tareas Trigger: guardados.
Almacenamiento: por cambios, con guardado como máximo cada 10 segundos si el valor no cambia.

13.2 Recomendaciones para producción

Reserva aproximadamente un 20% de margen sobre la configuración medida y repite las pruebas con scripts Lua, tamaños de mensaje y volumen histórico reales antes de producción.
La memoria base de AFE-E620 es elevada: el escenario base S1 ya supera 74% de media. Configura advertencia de CPU al 80%, advertencia de memoria al 85% y alarma grave al 90%. Supervisa cachés PostgreSQL y crecimiento de base de datos; si es necesario, evalúa reducir la cuota de memoria de PostgreSQL o utilizar un modelo de mayor capacidad.
Si necesitas almacenamiento en tiempo real, consulta S2, cuyo cumplimiento queda ligeramente por debajo del 99%. Si el negocio no lo exige, prioriza el almacenamiento por cambios de S2.5.
S3, con 5.000 puntos/s, y cargas superiores exceden la capacidad continua de AFE-E620, incluso con almacenamiento por cambios en S3.5. Para esa capacidad, utiliza AFE-E630.
S6 provoca una sobrecarga grave en E620 y no sirve como referencia de comprobación preliminar de estrés. Para validar protecciones ante sobrecarga, realiza pruebas breves con una carga del orden de S3.

14. Alertas de calidad y pruebas pendientes

Tiempos de espera de muestreo agotados: S1, 3; S2, 34; S2.5, 8; S3, 617; S3.5, 96; S6, 886. En sobrecarga, la propia supervisión no termina el muestreo a tiempo, reduciendo la fiabilidad de los recursos medidos. Prioriza volumen y latencia para evaluar esos escenarios.
Completa las versiones de CommBridge, Edge-EMS Builder y PostgreSQL utilizadas para documentar el entorno.
Ejecuta 72 horas completas de estabilidad, registrando reinicios, OOM, errores, pendiente de memoria y crecimiento de base de datos. Con la elevada base de memoria de E620, vigila especialmente un crecimiento lento y continuo.
Añade contadores de éxitos, fallos, tiempos de espera agotados y descartes para puntos, Trigger, MQTT y coordinación.
Completa medidas de rendimiento de disco, I/O wait, WAL/checkpoint de PostgreSQL, grupos de conexiones y profundidad de colas.
Investiga los casos Trigger de 10–11 segundos y los extremos simultáneos de unos 53 segundos en Trigger y MQTT de S3.5, correlacionando ID de tarea, Lua, SQL, GC, E/S y registros del sistema.
Registra tamaño inicial de base de datos, configuración PostgreSQL y calentamiento de cachés para mejorar la comparabilidad de memoria entre escenarios.

15. Limitaciones de los datos

El número de puntos es una carga configurada, no un recuento de éxitos por punto; los datos no demuestran de forma independiente que todos se escribieran correctamente.
La configuración funcional, incluidas agregaciones, composición de Trigger y tareas de coordinación, sigue las definiciones del manual; los libros no registran detalles por escenario.
Los libros no incluyen tasa de errores de negocio, estado de resultados ni tasa de corrección. Alcanzar el volumen no implica 100% de corrección funcional.
Son pruebas cortas de unos 33 minutos y 20 segundos por escenario, adecuadas para comparar rendimiento, no para sustituir estabilidad prolongada.
Las versiones de software no se registraron con los libros; la correspondencia entre versiones y resultados queda pendiente de completarlas.
S2.5 es la mayor carga probada del lote que alcanza el 99% de referencia. El margen del 20% es una recomendación de planificación, no una conclusión medida por separado.

Otro modelo: Informe AFE-E630.