Rapport de performances EMS Builder sur AFE-E630
Version du rapport : v1.3
Date des essais : 2026-07-29
Date du rapport : 2026-07-30
Méthode statistique : 2 002 acquisitions par scénario ; premier et dernier échantillons ignorés, statistiques sur les 2 000 échantillons de ressources validessample_no=2～2001
Manuel associé : Manuel des essais de performance Edge-EMS Builder
1. Vue d’ensemble des performances
Section intitulée « 1. Vue d’ensemble des performances »Acquisition configurée
Calculs agrégés
Objectif Trigger
Objectif des tâches MQTT
Tâches de coordination
Enregistrement au plus tard à 10 s
CPU machine, moyenne / P95
Mémoire machine, moyenne / P95
Trigger P95
MQTT P95
Chaque exécution Trigger représente une commande d’équipement, une alarme locale et MQTT, et une écriture de donnée agrégée. Edge-EMS Builder alloue les ressources PostgreSQL selon la mémoire de l’équipement ; l’occupation peut donc varier sensiblement selon le matériel, la taille de la base et l’état des caches.
1.1 Conclusion principale
Section intitulée « 1.1 Conclusion principale »Configuration recommandée sur AFE-E630 : scénario S3.5, avec 5 000 points/seconde, 30 calculs agrégés, 90 Trigger/seconde, 20 MQTT/seconde, 10 tâches de coordination/seconde et stockage sur changement toutes les 10 secondes au maximum.
Mesures S3.5 : 89,97 Trigger/seconde et 19,98 MQTT/seconde ; P95 Trigger / MQTT de 56 ms / 77 ms. P95 CPU de la machine : 71,09% ; P95 mémoire réelle : 41,41%. Aucune expiration d’échantillonnage n’a été observée.
Pour une exploitation durable, réservez environ 20% de marge d’ingénierie par rapport à S3.5. Le dimensionnement initial peut viser au plus environ 4 000 points/seconde, 72 Trigger/seconde, 16 MQTT/seconde et 8 tâches de coordination/seconde. Ces valeurs sont dérivées de la configuration mesurée et n’ont pas fait l’objet d’un scénario distinct. Avant production, retestez avec scripts, tailles de messages et historique de base réels.
1.2 État des scénarios
Section intitulée « 1.2 État des scénarios »| Icône | Scénario | Conclusion |
|---|---|---|
| 🟢 | S1 | Scénario de référence validé, marges importantes sur ressources et latences. |
| 🟢 | S2 | Réussi : fonctionnement stable à 2 000 points/seconde en stockage temps réel ; 1 expiration d’échantillonnage. |
| 🟢 | S2.5 | Réussi : le stockage sur changement réduit nettement la pression CPU par rapport à S2, sans expiration. |
| 🟡 | S3 | Indicateurs de tâches validés, mais P95 CPU de 81,06%, proche de la limite d’exploitation continue, et 2 expirations. |
| 🟢 | S3.5 | Meilleur résultat global, scénario actuellement recommandé sur AFE-E630. |
| 🔴 | S6 | Réservé à une prévalidation de charge courte : P95 CPU 94,02%, débit MQTT sous 99% et 11 expirations. |
2. Synthèse des conclusions
Section intitulée « 2. Synthèse des conclusions »- Six scénarios ont été testés : S1, S2, S2.5, S3, S3.5 et S6. Les autres sont exclus des tableaux, comparaisons et conclusions.
- À 5 000 points/seconde configurés, S3.5 atteint 99,97% pour Trigger et 99,90% pour MQTT ; leurs P95 sont de 56 ms et 77 ms.
- S3 et S3.5 ont la même charge métier. Le stockage sur changement réduit la moyenne CPU de 57,95% à 50,16% et le P95 de 81,06% à 71,09%, plus adaptés au fonctionnement continu.
- S6 atteint 99,49% pour Trigger mais 98,73% pour MQTT. Avec un P95 CPU de 94,02% et un pic de 100%, il est déconseillé pour une production continue.
- Le P99 global Trigger reste inférieur à 200 ms dans tous les scénarios, mais des exécutions extrêmes de 10 à 12 secondes subsistent. Le P99 MQTT de S6 atteint 236,62 ms, au-delà de 200 ms.
- Chaque scénario ne conserve que 2 000 secondes valides, soit environ 33 minutes 20 secondes. Ces données permettent une comparaison de performances, sans remplacer un essai de stabilité de 72 heures.
3. Méthode statistique
Section intitulée « 3. Méthode statistique »3.1 Sélection des échantillons
Section intitulée « 3.1 Sélection des échantillons »La surveillance compte les acquisitions. Les données brutes de chaque scénario contiennent sample_no=1～2002 :
Ignorer：sample_no = 1Comptabiliser：sample_no = 2～2001，2,000 au totalIgnorer：sample_no = 2002L’exclusion des premier et dernier échantillons évite les secondes incomplètes. Les résultats globaux Trigger et MQTT utilisent 2 000 secondes comme dénominateur. Une seconde sans enregistrement de tâche reste incluse dans le débit moyen, afin de ne pas le surestimer en ne comptant que les secondes actives.
3.2 Périmètre global EMS Builder
Section intitulée « 3.2 Périmètre global EMS Builder »Les 5 services suivants forment ensemble Edge-EMS Builder :
| Service | Fonction |
|---|---|
cb_core |
Acquisition de données et communication principale |
cb_nginx |
Web CommBridge / reverse proxy |
cb_backend |
Backend CommBridge |
ems_backend |
Calcul, stratégies et logique métier EMS Builder |
ems_postgresql |
Stockage des données EMS Builder |
Pour chaque sample_no, les 5 services sont d’abord additionnés ; moyenne, P95, P99 et pic sont ensuite calculés sur les 2 000 sommes. Les pics indépendants survenus à des instants différents ne sont pas additionnés.
3.3 CPU, mémoire et latence des tâches
Section intitulée « 3.3 CPU, mémoire et latence des tâches »- Les valeurs CPU brutes des cinq services sont exprimées en pourcentage équivalent monocœur. L’AFE-E630 possède 4 cœurs : CPU Edge-EMS Builder équivalent 4 cœurs = somme CPU des cinq services ÷ 4.
- Le CPU de la machine utilise
_system_totaldu classeur, normalisé sur toute la capacité CPU de 0 à 100%. C’est l’indicateur principal de capacité. - La mémoire attribuée à Edge-EMS Builder additionne la mémoire cgroup des cinq services. Pages partagées et caches peuvent être attribués plusieurs fois ; cette somme peut dépasser la mémoire réellement utilisée et ne doit pas être divisée directement par la mémoire physique pour obtenir un taux d’occupation.
- La mémoire réelle de la machine est
MemTotal - MemAvailable, indicateur principal de marge physique. - Moyennes et P50, P95, P99 Trigger / MQTT portent sur tous les enregistrements de tâches de la période valide, et non sur les moyennes par seconde.
- Tous les classeurs ont passé la vérification de l’arrêt de charge avant consolidation : Trigger, MQTT et CommBridge ont été arrêtés, puis une attente de 30 secondes a précédé la consolidation.
4. Équipement et environnement
Section intitulée « 4. Équipement et environnement »| Élément | Configuration |
|---|---|
| Modèle | AFE-E630 |
| CPU | Arm Cortex-A55, 4 cœurs |
| Mémoire | 3,81 GB DDR4 |
| Système d’exploitation | JelinaOS, basé sur Debian 11 |
| Stockage | eMMC |
| Versions logicielles | CommBridge-rc-2026-07-08T17-52-07 ; EMS Builder v1.2 ; PostgreSQL v18.3 |
| Réseau | Réseau local ; MQTT / TCP |
| Échantillonnage de surveillance | Une acquisition par seconde ; 2 002 par scénario, statistiques sur les 2 000 centrales |
| Sources des essais | 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. Scénarios et charges
Section intitulée « 5. Scénarios et charges »| Scénario | Acquisition | Calculs agrégés | Trigger ordinaires | Trigger 100 ms | Objectif Trigger | Objectif MQTT | Coordination | Stockage |
|---|---|---|---|---|---|---|---|---|
| S1 | 500 points/seconde | 10 | 10 /seconde | 0 | 10 /seconde | 5 /seconde | 0 /seconde | Temps réel |
| S2 | 2 000 points/seconde | 20 | 20 /seconde | 2 | 40 /seconde | 10 /seconde | 2 /seconde | Temps réel |
| S2.5 | 2 000 points/seconde | 20 | 20 /seconde | 2 | 40 /seconde | 10 /seconde | 2 /seconde | Sur changement (10 secondes) |
| S3 | 5 000 points/seconde | 30 | 50 /seconde | 4 | 90 /seconde | 20 /seconde | 10 /seconde | Temps réel |
| S3.5 | 5 000 points/seconde | 30 | 50 /seconde | 4 | 90 /seconde | 20 /seconde | 10 /seconde | Sur changement (10 secondes) |
| S6 | 5 000 points/seconde | 20 | 50 /seconde | 10 | 150 /seconde | 30 /seconde | 15 /seconde | Temps réel |
L’acquisition représente la charge configurée du scénario. Les classeurs actuels ne fournissent pas le nombre de réussites par point ; cette charge ne constitue donc pas un débit d’écriture réussie vérifié indépendamment.
6. Périodes d’essai
Section intitulée « 6. Périodes d’essai »| Scénario | Intervalle statistique valide | Durée valide |
|---|---|---|
| S1 | 2026-07-29 17:18:09 ～ 17:51:29 | 2 000 secondes |
| S2 | 2026-07-29 17:54:29 ～ 18:27:49 | 2 000 secondes |
| S2.5 | 2026-07-29 18:31:54 ～ 19:05:14 | 2 000 secondes |
| S3 | 2026-07-29 19:09:20 ～ 19:42:40 | 2 000 secondes |
| S3.5 | 2026-07-29 19:47:06 ～ 20:20:26 | 2 000 secondes |
| S6 | 2026-07-29 20:24:47 ～ 20:58:07 | 2 000 secondes |
Toutes les heures sont en UTC+8.
7. Résultats CPU
Section intitulée « 7. Résultats CPU »7.1 Somme des cinq services EMS Builder, équivalent 4 cœurs
Section intitulée « 7.1 Somme des cinq services EMS Builder, équivalent 4 cœurs »| État | Scénario | Moyenne | P95 | P99 | Pic |
|---|---|---|---|---|---|
| 🟢 | 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% |
Le pic Edge-EMS Builder de 208,59% dans S6 est une anomalie sur une fenêtre d’échantillonnage, correspondant à un temps CPU cumulé des cinq services supérieur à la capacité normale de 4 cœurs. Avec les 11 expirations observées, cela peut indiquer un chevauchement des fenêtres ou un ordonnancement en rafale. Ce pic n’est pas considéré comme une occupation soutenable.
7.2 CPU de la machine, normalisé sur toute sa capacité
Section intitulée « 7.2 CPU de la machine, normalisé sur toute sa capacité »| État | Scénario | Moyenne | P95 | P99 | Pic |
|---|---|---|---|---|---|
| 🟢 | 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% |
Le CPU de la machine est le critère principal de capacité CPU. Le P95 S3.5 est inférieur de 9,97 points à celui de S3. Le P95 S6 dépasse 90%, sans marge suffisante pour une exploitation continue.
8. Résultats mémoire
Section intitulée « 8. Résultats mémoire »| État | Scénario | Mémoire attribuée EMS Builder, moyenne | Mémoire attribuée EMS Builder, P95 | Mémoire réelle machine, moyenne | Mémoire réelle machine, P95 | Mémoire réelle machine, pic |
|---|---|---|---|---|---|---|
| 🟢 | 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 mémoire attribuée aux cinq services inclut pages partagées et caches cgroup et n’équivaut pas à une occupation physique nette. La mémoire réelle reflète mieux la capacité restante et sert à l’évaluation. L’état initial de la base et le réchauffement des caches varient entre scénarios ; le nombre de points seul ne permet pas de déduire l’évolution mémoire.
9. Débit de traitement
Section intitulée « 9. Débit de traitement »Le débit moyen utilise toute la période valide de 2 000 secondes. Le taux d’atteinte divise le nombre total de tâches par l’objectif total, pour éviter les erreurs d’arrondi des valeurs affichées dans les classeurs.
| État | Scénario | Total Trigger | Moyenne / objectif Trigger | Atteinte Trigger | Total MQTT | Moyenne / objectif MQTT | Atteinte 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% |
Le rapport utilise 99% comme référence de débit pour les scénarios recommandés. MQTT dans S6 reste en dessous ; CPU élevé, latences croissantes et expirations simultanées indiquent une zone de forte pression.
10. Latence Trigger
Section intitulée « 10. Latence Trigger »Les percentiles suivants portent sur toutes les tâches Trigger de la période valide, en millisecondes.
| État | Scénario | Moyenne | P50 | P95 | P99 | Maximum individuel |
|---|---|---|---|---|---|---|
| 🟢 | 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 |
Les percentiles usuels sont faibles, mais tous les scénarios présentent des exécutions extrêmes d’environ 10 à 12 secondes. Elles changent peu le P99 mais peuvent affecter certaines commandes ou alarmes et doivent être investiguées séparément.
11. Latence MQTT
Section intitulée « 11. Latence MQTT »Les percentiles suivants portent sur toutes les tâches MQTT de la période valide, en millisecondes.
| État | Scénario | Moyenne | P50 | P95 | P99 | Maximum individuel |
|---|---|---|---|---|---|---|
| 🟢 | 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. Évaluation des scénarios
Section intitulée « 12. Évaluation des scénarios »| Scénario | Verdict | Principaux éléments |
|---|---|---|
| S1 | Réussi | Sous charge de référence : P95 CPU 38,67%, P95 mémoire 41,97%, objectifs de débit atteints. |
| S2 | Réussi | Atteinte Trigger et MQTT proche de 100%, avec une marge de ressources importante ; surveiller l’unique expiration. |
| S2.5 | Réussi | Débit atteint ; le stockage sur changement réduit nettement moyenne et P95 CPU par rapport à S2. |
| S3 | Réussi sous conditions | Débit et latence conformes, mais P95 CPU 81,06%, 2 expirations et marge réduite en exploitation continue. |
| S3.5 | Recommandé | À 5 000 points/seconde, P95 Trigger et MQTT sous 100 ms, P95 CPU 71,09%, P95 mémoire réelle 41,41%, aucune expiration. |
| S6 | Exploitation continue déconseillée | Atteinte MQTT 98,73%, P99 236,62 ms, P95 CPU 94,02% et 11 expirations. |
13. Recommandations de capacité et de déploiement
Section intitulée « 13. Recommandations de capacité et de déploiement »13.1 Configuration recommandée validée
Section intitulée « 13.1 Configuration recommandée validée »- Acquisition configurée : 5 000 points/seconde.
- Calculs agrégés : 30.
- Trigger ordinaires : 50/seconde.
- Trigger 100 ms : 4, soit 40/seconde.
- Total Trigger : 90/seconde.
- MQTT : 20/seconde.
- Coordination : 10 tâches/seconde.
- Enregistrements des tâches Trigger : conservés.
- Stockage sur changement, avec enregistrement au plus tard toutes les 10 secondes si la valeur reste identique.
13.2 Déploiement en production
Section intitulée « 13.2 Déploiement en production »- Pour une exploitation durable, conservez environ 20% de marge sur cette configuration mesurée et retestez avant mise en service avec scripts Lua, tailles de messages et historique réels.
- Configurez un avertissement CPU à 80%, mémoire à 70% et une alarme mémoire critique à 80%. Surveillez continuellement les caches PostgreSQL et la croissance de la base.
- Si le stockage temps réel est nécessaire, référez-vous à S3, dont le P95 CPU dépasse 80%. Sinon, privilégiez le stockage sur changement S3.5.
- Réservez S6 aux essais brefs de charge, limitation de débit ou protection contre la surcharge ; il est déconseillé comme charge de production continue sur E630.
14. Alertes de qualité et essais complémentaires
Section intitulée « 14. Alertes de qualité et essais complémentaires »- Expirations d’échantillonnage : 1 dans S2, 2 dans S3 et 11 dans S6 ; aucune dans S1, S2.5 et S3.5.
- Réaliser les 72 heures de stabilité complètes en suivant redémarrages de processus, OOM, erreurs, pente mémoire et croissance de la base.
- Ajouter des compteurs de réussite, échec, expiration et abandon pour acquisition, Trigger, MQTT et coordination.
- Mesurer débit disque, I/O wait, WAL / checkpoint PostgreSQL, pools de connexions et profondeur des files.
- Corréler les exécutions Trigger de 10 à 12 secondes avec IDs de tâches, Lua, SQL, GC, I/O et journaux système.
- Enregistrer avant chaque scénario taille de base, configuration PostgreSQL et état des caches pour améliorer la comparabilité mémoire.
15. Limites des données
Section intitulée « 15. Limites des données »- Le nombre de points est une charge configurée, sans comptage des réussites par point. Les données ne prouvent pas indépendamment que chaque point a été écrit avec succès.
- Les classeurs ne contiennent pas de taux d’erreur métier, d’état de résultat ou d’exactitude. Un débit atteint ne signifie pas 100% de résultats métier corrects.
- Chaque scénario dure environ 33 minutes 20 secondes et permet une comparaison de performances, sans remplacer une stabilité longue durée.
- S3.5 est la configuration testée de cette campagne offrant le meilleur ensemble d’indicateurs. La marge de 20% est une recommandation de dimensionnement, pas une mesure indépendante.
Autre modèle : Rapport AFE-E620.