Informe de rendimiento de EMS Builder en AFE-E630
Versión del informe: v1.3
Fecha de prueba: 2026-07-29
Fecha del informe: 2026-07-30
Metodología: 2.002 muestras por escenario, excluyendo la primera y la última; solo se analizan las 2.000 muestras válidas de recursos consample_no=2～2001.
Manual relacionado: Pruebas de rendimiento de Edge-EMS Builder
1. Resumen de resultados de rendimiento
Sección titulada «1. Resumen de resultados de rendimiento»Carga de adquisición configurada
Agregaciones
Objetivo Trigger
Objetivo de tareas MQTT
Tareas de coordinación
Guardado cada 10 s como máximo
CPU del equipo: media / P95
Memoria del equipo: media / P95
Trigger P95
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é.
1.1 Conclusión principal
Sección titulada «1.1 Conclusión principal»Se recomienda ejecutar AFE-E630 con S3.5: 5.000 puntos/s, 30 agregaciones, 90 Trigger/s, 20 tareas MQTT/s y 10 tareas de coordinación/s, con almacenamiento por cambios de 10 segundos.
S3.5 procesó 89,97 Trigger/s y 19,98 MQTT/s. Sus P95 fueron 56 ms y 77 ms. La CPU P95 del equipo fue 71,09% y la memoria real P95, 41,41%, sin tiempos de espera de muestreo agotados.
Para producción prolongada, reserva aproximadamente un 20% de margen de ingeniería respecto a S3.5. La planificación inicial puede limitarse a aproximadamente 4.000 puntos/s, 72 Trigger/s, 16 MQTT/s y 8 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
Sección titulada «1.2 Estado de cada escenario»| Icono | Escenario | Conclusión |
|---|---|---|
| 🟢 | S1 | Escenario base superado, con margen suficiente de recursos y latencia. |
| 🟢 | S2 | Superado; funcionamiento estable con 2.000 puntos/s y almacenamiento en tiempo real; un tiempo de espera de muestreo agotado. |
| 🟢 | S2.5 | Superado; el almacenamiento por cambios reduce claramente la carga de CPU frente a S2, sin tiempos de espera de muestreo agotados. |
| 🟡 | S3 | Indicadores de tareas superados, pero CPU P95 de 81,06%, cerca del límite de funcionamiento continuo; dos tiempos de espera de muestreo agotados. |
| 🟢 | S3.5 | Mejor resultado global; escenario recomendado actualmente para AFE-E630. |
| 🔴 | S6 | Solo adecuado como comprobación breve de estrés: CPU P95 de 94,02%, volumen MQTT por debajo del 99% recomendado y 11 tiempos de espera de muestreo agotados. |
2. Síntesis de conclusiones
Sección titulada «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 5.000 puntos/s configurados, S3.5 alcanzó 99,97% en Trigger y 99,90% en MQTT; los P95 fueron 56 ms y 77 ms.
- S3 y S3.5 tienen la misma carga funcional. El almacenamiento por cambios redujo la CPU media de 57,95% a 50,16% y P95 de 81,06% a 71,09%, favoreciendo el funcionamiento continuo.
- S6 alcanzó 99,49% en Trigger, pero 98,73% en MQTT. La CPU P95 fue 94,02% y el máximo 100%; no se recomienda como configuración continua de producción.
- Trigger P99 quedó por debajo de 200 ms en todos los escenarios, aunque hubo ejecuciones individuales de unos 10–12 segundos. MQTT P99 en S6 fue 236,62 ms, superior a 200 ms.
- 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
Sección titulada «3. Metodología estadística»3.1 Selección de muestras
Sección titulada «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 = 1Analizar: sample_no = 2–2001, 2,000 muestrasExcluir: sample_no = 2002Excluir 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
Sección titulada «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
Sección titulada «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-E630 tiene cuatro núcleos: «CPU equivalente de EMS Builder sobre cuatro núcleos» = suma de los cinco servicios ÷ 4.
- «CPU del equipo» utiliza
_system_totaldel 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 - MemAvailabley es la referencia principal para evaluar el margen de memoria física. - 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
Sección titulada «4. Equipo y entorno de prueba»| Elemento | Configuración |
|---|---|
| Modelo de equipo | AFE-E630 |
| CPU | Arm Cortex-A55, 4 núcleos |
| Memoria | 3,81 GB DDR4 |
| Sistema operativo | JelinaOS, basado en Debian 11 |
| Almacenamiento | eMMC |
| Versión de software | CommBridge-rc-2026-07-08T17-52-07；EMS Builder v1.2；PostgreSQL v18.3 |
| 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_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. Escenarios y cargas
Sección titulada «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. Los libros no proporcionan recuentos de éxito por punto; no puede presentarse como un caudal de inserción correcta en base de datos validado independientemente.
6. Horarios de prueba
Sección titulada «6. Horarios de prueba»| Escenario | Intervalo estadístico válido | Duración válida |
|---|---|---|
| S1 | 2026-07-29 17:18:09 ～ 17:51:29 | 2.000 s |
| S2 | 2026-07-29 17:54:29 ～ 18:27:49 | 2.000 s |
| S2.5 | 2026-07-29 18:31:54 ～ 19:05:14 | 2.000 s |
| S3 | 2026-07-29 19:09:20 ～ 19:42:40 | 2.000 s |
| S3.5 | 2026-07-29 19:47:06 ～ 20:20:26 | 2.000 s |
| S6 | 2026-07-29 20:24:47 ～ 20:58:07 | 2.000 s |
Todos los horarios están en UTC+8.
7. Resultados de CPU
Sección titulada «7. Resultados de CPU»7.1 Total de los cinco servicios de EMS Builder, equivalente a cuatro núcleos
Sección titulada «7.1 Total de los cinco servicios de EMS Builder, equivalente a cuatro núcleos»| Estado | Escenario | Media | P95 | P99 | Máximo |
|---|---|---|---|---|---|
| 🟢 | 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% |
El máximo de EMS Builder de 208,59% en S6 es una anomalía de una ventana de muestreo: el tiempo de CPU acumulado de los cinco servicios supera la capacidad habitual de cuatro núcleos. Junto con los 11 tiempos de espera de muestreo agotados, puede indicar ventanas que abarcan periodos distintos o ráfagas de planificación. No se considera un consumo sostenible.
7.2 CPU del equipo, normalizada a toda la capacidad
Sección titulada «7.2 CPU del equipo, normalizada a toda la capacidad»| Estado | Escenario | Media | P95 | P99 | Máximo |
|---|---|---|---|---|---|
| 🟢 | 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% |
La CPU del equipo es la referencia principal de capacidad. S3.5 tiene un P95 9,97 puntos porcentuales inferior a S3. S6 supera 90% de P95 y carece de margen suficiente para funcionar continuamente.
8. Resultados de memoria
Sección titulada «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 | 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%） |
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. 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
Sección titulada «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 | 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% |
La referencia para recomendar un escenario es 99%. MQTT en S6 queda por debajo y coincide con CPU elevada, más latencia y tiempos de espera de muestreo agotados, lo que indica una carga en zona de estrés.
10. Latencia de Trigger
Sección titulada «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 | 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 |
Los percentiles habituales son bajos, pero todos los escenarios presentan ejecuciones extremas de unos 10–12 segundos. Estos casos apenas alteran P99, aunque pueden afectar a controles o alarmas individuales y requieren investigación específica.
11. Latencia de MQTT
Sección titulada «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 | 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. Evaluación de escenarios
Sección titulada «12. Evaluación de escenarios»| Escenario | Evaluación | Fundamento principal |
|---|---|---|
| S1 | Superado | Con carga base, CPU P95 de 38,67%, memoria P95 de 41,97% y volumen de tareas conforme al objetivo. |
| S2 | Superado | Trigger y MQTT se acercan al 100%, con amplio margen de recursos; revisar un tiempo de espera de muestreo agotado. |
| S2.5 | Superado | Volumen conforme al objetivo; con almacenamiento por cambios, CPU media y P95 claramente inferiores a S2. |
| S3 | Superado con condiciones | Volumen y latencia conformes, pero CPU P95 de 81,06% y dos tiempos de espera de muestreo agotados; margen reducido para funcionamiento continuo. |
| S3.5 | Recomendado | Con 5.000 puntos/s, Trigger / MQTT P95 inferiores a 100 ms, CPU P95 de 71,09%, memoria real P95 de 41,41% y sin tiempos de espera de muestreo agotados. |
| S6 | No recomendado para funcionamiento continuo | MQTT alcanza 98,73%, con P99 de 236,62 ms; CPU P95 de 94,02% y 11 tiempos de espera de muestreo agotados. |
13. Recomendaciones de capacidad y despliegue
Sección titulada «13. Recomendaciones de capacidad y despliegue»13.1 Configuración recomendada validada
Sección titulada «13.1 Configuración recomendada validada»- Adquisición configurada: 5.000 puntos/s.
- Agregaciones: 30.
- Trigger normales: 50/s.
- Trigger de 100 ms: 4, equivalentes a 40/s.
- Total Trigger: 90/s.
- MQTT: 20/s.
- Coordinación: 10 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
Sección titulada «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.
- Configura advertencia de CPU del equipo al 80%, advertencia de memoria al 70% y alarma grave al 80%. Supervisa las cachés PostgreSQL y el crecimiento de la base de datos.
- Si necesitas almacenamiento en tiempo real, consulta S3, cuyo CPU P95 ya supera 80%. Si el negocio no lo exige, prioriza el almacenamiento por cambios de S3.5.
- Utiliza S6 solo para pruebas breves de estrés, limitación o protección ante sobrecarga, no como carga continua de producción en E630.
14. Alertas de calidad y pruebas pendientes
Sección titulada «14. Alertas de calidad y pruebas pendientes»- Hubo un tiempo de espera de muestreo agotado en S2, dos en S3 y once en S6. No se detectaron en S1, S2.5 ni S3.5.
- Ejecuta las 72 horas completas de estabilidad y registra reinicios, OOM, errores, pendiente de memoria y crecimiento de base de datos.
- 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.
- Correlaciona los casos Trigger de 10–12 segundos con ID de tarea, scripts 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
Sección titulada «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.
- 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.
- S3.5 ofrece los mejores indicadores globales del lote. El margen del 20% es una recomendación de planificación, no una conclusión medida por separado.
Otro modelo: Informe AFE-E620.