Manuel des essais de performance EMS Builder

Version du manuel : v1.1
Règle statistique actuelle : ajouter 2 acquisitions, une au début et une à la fin ; les résultats officiels portent uniquement sur les échantillons intermédiaires.

Conditions d’essai : aucun instrument réel, automate ni passerelle série n’est connecté. Tous les équipements sont simulés en Modbus TCP. Les résultats représentent la capacité de traitement d’Edge-EMS Builder dans des communications idéales, et non les performances de bout en bout d’un site réel.

1. Contenu des essais

Élément testé	Question à résoudre
Acquisition	Combien de points EMS Builder traite-t-il de façon stable par seconde ?
Trigger	Les tâches Lua respectent-elles le planning et une durée stable ?
MQTT / coordination	Les objectifs de tâches sont-ils atteints, sans retard ni échec ?
Stockage	Quel effet ont le stockage temps réel et le stockage sur changement ?
Ressources système	CPU, mémoire et disque approchent-ils de leurs limites ?
Stabilité	Un fonctionnement prolongé provoque-t-il plantages, redémarrages ou accumulation continue ?

2. Charges d’essai

2.1 Travaux simultanés d’EMS Builder

Charge	Contenu de l’essai
Acquisition	Lire les points de 20 esclaves simulés
Agrégation	Calculer sur les données acquises avec Lua
Trigger	Exécuter Lua périodiquement et produire écritures, alarmes et actions MQTT
Tâches MQTT	Générer et publier des messages périodiquement
Coordination	Partager des données et coordonner les équipements
Stockage	Conserver données acquises, résultats de calcul et enregistrements de tâches

2.2 Que fait chaque script Lua Trigger ?

Opération	Nombre par exécution	Rôle
Boucle de calcul de base	100	Calculs mathématiques, conditions, boucles, chaînes et tables
Écriture de points bruts	2	Écrire les points de test `小数据0` et `小数据1`
Écriture d’un point agrégé	1	Écrire le point de test `Agg`
Alarme locale	2	Générer deux alarmes de niveau 1
Alarme MQTT	1	Générer une alarme MQTT de niveau 2

2.3 Charge réelle par seconde

Indicateur	Calcul	Par seconde
Exécutions Lua	Trigger : `50 tâches à 1s + 5 tâches à 100ms = 100/s`, MQTT : `50/s`, agrégation : `50/s`, partage : `10/s`	210
Boucles de base Trigger	`100 × 100`	10 000
Écritures de points bruts Trigger	`100 × 2`	200
Écritures de points agrégés Trigger	`100 × 1`	100
Alarmes locales Trigger	`100 × 2`	200
Alarmes MQTT Trigger	`100 × 1`	100
Toutes les écritures Trigger	`100 × 6`	600
Publications MQTT	`50 × 1`	50
Agrégations déclenchées par changement	`50 × 1`	50
Tâches de partage	`10 × 1`	10

3. Scénarios standard

Calcul :

Trigger Nombre/seconde = 1s Trigger Nombre + 100ms Trigger Nombre × 10

Scénario	Points acquis/s	Agrégations	Trigger 1s	Trigger 100ms	Trigger/s	MQTT/s	Coordination/s	Stockage	Durée
S1	500	10	10	0	10	5	0	Temps réel	30 minutes
S2	2 000	20	20	2	40	10	2	Temps réel	30 minutes
S2.5	2 000	20	20	2	40	10	2	Sur changement	30 minutes
S3	5 000	30	50	4	90	20	10	Temps réel	30 minutes
S3.5	5 000	30	50	4	90	20	10	Sur changement	30 minutes
S4	10 000	30	100	10	200	40	20	Sur changement	30 minutes
S5	20 000	40	200	10	300	60	40	Sur changement	30 minutes
S6	5 000	20	50	10	150	30	15	Temps réel	72 heures

Mode de stockage	Description
Temps réel	Enregistrer chaque résultat d’acquisition selon la configuration
Sur changement	Enregistrer immédiatement en cas de changement, sinon au moins toutes les 10 secondes

S5 sert à rechercher la limite de performance ; S6 doit réellement fonctionner pendant 72 heures.

4. Échantillonnage et statistiques

4.1 Échantillonnage par nombre fixe

Les reprises d’essais courts utilisent un nombre fixe d’acquisitions. Exemple : 1 002 acquisitions espacées d’une seconde donnent 1 000 échantillons intermédiaires valides. La campagne AFE-E630 du 2026-07-29 (rapport v1.3) utilise en réalité 2 002 acquisitions et 2 000 échantillons valides par scénario :

1er : échantillon de bord, exclu
2e à 1001e : échantillons valides, 1,000 au total
1002e : échantillon de bord, exclu

Le rapport officiel doit filtrer raw_data par sample_no, sans utiliser directement les totaux de tous les échantillons, début et fin compris, de la feuille summary.

Pour 30 minutes complètes à une seconde d’intervalle, acquérez 1 802 échantillons et analysez les 1 800 centraux. Les 1 002 acquisitions de l’exemple court ne remplacent pas les 72 heures de stabilité de S6.

4.2 Ressources globales EMS Builder

Les 5 services suivants doivent être additionnés pour un même sample_no avant le calcul statistique :

cb_core
cb_nginx
cb_backend
ems_backend
ems_postgresql

AEMS_CPU_raw(n) = Somme CPU des 5 services pour un même sample_no
CPU machine 4 cœurs(n) = AEMS_CPU_raw(n) ÷ 4
Mémoire Edge-EMS Builder(n) = Somme mémoire des 5 services pour un même sample_no

Le rapport doit au minimum présenter moyenne, P95, P99 et pic. N’additionnez pas les pics indépendants des cinq services survenus à des instants différents.

4.3 Trigger et MQTT

Après tri chronologique de trigger_per_sec et mqtt_per_sec, excluez aussi les premier et dernier intervalles d’une seconde, qui peuvent être incomplets aux limites de la requête.

Les intervalles de tâches ne correspondent pas forcément exactement aux acquisitions de ressources : une seconde peut être vide, ou les tâches accumulées terminer à la seconde suivante. Le rapport doit indiquer le nombre d’intervalles valides et fournir :

le débit moyen par seconde et le taux d’atteinte de l’objectif ;
moyenne, P50, P95 et P99 des moyennes par seconde de SpendTime ;
le maximum individuel de SpendTime sur tous les intervalles ;
le nombre et la proportion de secondes dont la moyenne de SpendTime dépasse 200 ms.

Une seconde complète sans tâche compte pour 0 dans le débit. Elle n’a pas de latence calculable et ne doit pas être artificiellement assimilée à 0 ms. Les futurs scripts de surveillance doivent fournir les bornes précises de la fenêtre statistique pour compléter les secondes vides.

5. Indicateurs observés

Catégorie	Statistiques requises
Acquisition	Points configurés, réussis, échoués et abandonnés
Trigger	Nombre cible, réel, durée moyenne, P50, P95, P99, maximum
MQTT / coordination	Nombre cible, réel, durée et erreurs
CPU	Moyenne, P95 et pic de l’ensemble EMS Builder
Mémoire	Moyenne, pic et tendance de l’ensemble EMS Builder
Disque	Débits de lecture/écriture, attente I/O, état des écritures en base
Modbus	Nombre de lectures/écritures, échecs, expirations et tentatives par esclave
Stabilité	Plantages, OOM, redémarrages anormaux, accumulation continue

Calculs essentiels :

Taux d’exactitude = Réussites ÷（Réussites + Échecs + Expirations + Abandons）

Taux d’atteinte = Débit moyen réel par seconde ÷ Objectif du scénario

SpendTime est la durée réelle d’exécution d’une tâche. Outre la moyenne, le rapport doit présenter P95, P99 et maximum pour identifier les retards longs occasionnels.

6. Évaluation des résultats

Le contrat du projet ou la spécification de réception prévaut. Sans accord particulier, utilisez les références suivantes.

Élément	Critère recommandé
Débit	Taux moyen d’atteinte ≥ 99%
Durée Trigger / MQTT	P95 < 200 ms
CPU	Moyenne < 80% sur 4 cœurs, sans saturation continue
Mémoire	Moyenne machine < 70%, sans croissance continue
Exactitude	≥ 99,99%, sans abandon inexpliqué
Stabilité	72 heures continues sans plantage, OOM ni redémarrage anormal
Reprise	Retour à un état stable sous 5 minutes après réduction de la charge

6.1 Conditions invalidant l’essai

Situation	Traitement
Durée insuffisante	Marquer « Inachevé »
Les 20 esclaves ne participent pas tous	Refaire l’essai
Écritures concentrées sur quelques esclaves	Répartir à nouveau puis retester
Générateur de charge ou réseau limitant	Corriger puis retester
Données de réussite, échec ou expiration manquantes	Marquer « Données incomplètes »
S6 n’a pas duré 72 heures	Ne pas annoncer une stabilité validée

S4 et S5 sont des essais de charge. À la limite du système, indiquez « Limite de charge atteinte » ou « Exploitation continue déconseillée », sans présenter la capacité normale comme validée.

Rapports par modèle :

Informations associées :