Handbuch für Leistungstests mit EMS Builder

Handbuchversion: v1.1
Aktuelle Auswertungsregel: Bei einer festgelegten Anzahl von Messungen werden am Anfang und Ende zwei zusätzliche Messungen erfasst. Das offizielle Ergebnis berücksichtigt nur die dazwischenliegenden Messwerte.

Testhinweis: In diesem Test werden keine realen Messgeräte, SPSen oder seriellen Gateways angeschlossen. Es werden ausschließlich simulierte Modbus-TCP-Geräte verwendet. Die Ergebnisse beschreiben die Verarbeitungskapazität von Edge-EMS Builder unter idealen Kommunikationsbedingungen, nicht die Ende-zu-Ende-Leistung einer realen Anlage.

1. Testumfang

Testbereich	Zu beantwortende Frage
Datenerfassung	Wie viele Datenpunkte pro Sekunde kann EMS Builder stabil verarbeiten?
Trigger	Werden Lua-Aufgaben planmäßig ausgeführt? Ist ihre Ausführungsdauer stabil?
MQTT / Koordinationsaufgaben	Wird die vorgesehene Aufgabenanzahl erreicht? Treten Verzögerungen oder Fehler auf?
Datenspeicherung	Wie wirken sich Echtzeitspeicherung und Speicherung bei Änderungen auf die Leistung aus?
Systemressourcen	Nähern sich CPU, Arbeitsspeicher und Datenträger ihren Kapazitätsgrenzen?
Stabilität	Treten bei langem Betrieb Abstürze, Neustarts oder anhaltende Rückstaus auf?

2. Testlast

2.1 Gleichzeitig von EMS Builder ausgeführte Arbeiten

Last	Testinhalt
Datenerfassung	Datenpunkte von 20 simulierten Slaves lesen
Aggregationsberechnungen	Erfasste Daten mit Lua berechnen
Trigger	Lua-Skripte zeitgesteuert ausführen und Schreib-, Warn- sowie MQTT-Aktionen auslösen
MQTT-Aufgaben	MQTT-Nachrichten zeitgesteuert erzeugen und veröffentlichen
Koordinationsaufgaben	Geräteübergreifende Datenfreigabe und koordinierte Verarbeitung ausführen
Datenspeicherung	Erfasste Daten, Berechnungsergebnisse und Aufgabenprotokolle speichern

2.2 Was führt das Lua-Skript bei jedem Trigger-Aufruf aus?

Inhalt	Anzahl je Ausführung	Zweck
Grundlegende Berechnungsschleife	100	Mathematische Berechnungen, Bedingungen, Schleifen sowie String- und Tabellenoperationen ausführen
Schreiben von Rohdatenpunkten	2	Jeweils in die Testdatenpunkte `小数据0` und `小数据1` schreiben
Schreiben von Aggregationsdatenpunkten	1	In den Testaggregationspunkt `Agg` schreiben
Lokale Warnungen	2	Zwei Warnungen der Stufe 1 erzeugen
MQTT-Warnung	1	Eine MQTT-Warnung der Stufe 2 erzeugen

2.3 Tatsächliche Last pro Sekunde

Kennzahl	Berechnung	Pro Sekunde
Lua-Skriptausführungen	Trigger-Aufgaben: `50 × 1 s + 5 × 100 ms = 100/s`, MQTT-Aufgaben: `50/s`, Aggregationsberechnungen: `50/s`, Freigabeaufgaben: `10/s`	210
Grundlegende Trigger-Berechnungsschleifen	`100 × 100`	10.000
Trigger-Schreibvorgänge für Rohdatenpunkte	`100 × 2`	200
Trigger-Schreibvorgänge für Aggregationsdatenpunkte	`100 × 1`	100
Lokale Trigger-Warnungen	`100 × 2`	200
Trigger-MQTT-Warnungen	`100 × 1`	100
Sämtliche Trigger-Schreibaktionen	`100 × 6`	600
Veröffentlichte MQTT-Nachrichten	`50 × 1`	50
Durch Datenänderungen ausgelöste Aggregationsberechnungen	`50 × 1`	50
Datenfreigabeaufgaben	`10 × 1`	10

3. Standardszenarien

Berechnung:

Trigger/s = Anzahl der 1-s-Trigger + Anzahl der 100-ms-Trigger × 10

Szenario	Erfasste Datenpunkte/s	Aggregationen	1-s-Trigger	100-ms-Trigger	Trigger/s	MQTT/s	Koordination/s	Speicherung	Dauer
S1	500	10	10	0	10	5	0	Echtzeit	30 Minuten
S2	2.000	20	20	2	40	10	2	Echtzeit	30 Minuten
S2.5	2.000	20	20	2	40	10	2	Bei Änderungen	30 Minuten
S3	5.000	30	50	4	90	20	10	Echtzeit	30 Minuten
S3.5	5.000	30	50	4	90	20	10	Bei Änderungen	30 Minuten
S4	10.000	30	100	10	200	40	20	Bei Änderungen	30 Minuten
S5	20.000	40	200	10	300	60	40	Bei Änderungen	30 Minuten
S6	5.000	20	50	10	150	30	15	Echtzeit	72 Stunden

Speicherverfahren	Beschreibung
Echtzeitspeicherung	Jedes Erfassungsergebnis gemäß Konfiguration speichern
Speicherung bei Änderungen	Bei Wertänderung sofort speichern; bei unverändertem Wert mindestens einmal alle 10 Sekunden speichern

S5 dient zur Ermittlung der Leistungsgrenze. S6 muss tatsächlich 72 Stunden lang ausgeführt werden.

4. Mess- und Auswertungsregeln

4.1 Feste Anzahl von Messungen

Kurze Wiederholungstests verwenden eine feste Anzahl von Messungen, die sich nach dem Bericht der jeweiligen Testreihe richtet. Das folgende Beispiel erfasst je Szenario 1.002 Messungen im Abstand von einer Sekunde. Der AFE-E630-Bericht v1.3 verwendet 2.002 Messungen mit 2.000 gültigen Messwerten:

Messung 1: Randmessung, nicht auswerten
Messungen 2–1001: reguläre Messwerte, insgesamt 1.000
Messung 1002: Randmessung, nicht auswerten

Für den offiziellen Bericht muss raw_data anhand von sample_no gefiltert werden. Die Gesamtauswertung im Arbeitsblatt summary, die auch die erste und letzte Messung enthält, darf nicht direkt übernommen werden.

Bei einem vollständigen 30-Minuten-Test mit einem Messintervall von einer Sekunde sind 1.802 Messungen zu erfassen und die mittleren 1.800 auszuwerten. Der 72-Stunden-Stabilitätstest S6 darf nicht durch 1.002 Kurzzeitmessungen ersetzt werden.

4.2 Ressourcen von EMS Builder insgesamt

Die folgenden fünf Dienste müssen zunächst für dieselbe sample_no summiert werden. Erst danach werden die statistischen Kennzahlen berechnet:

cb_core
cb_nginx
cb_backend
ems_backend
ems_postgresql

AEMS_CPU_raw(n) = CPU-Summe der 5 Dienste bei derselben sample_no
4-Kern-Gesamtsystem-CPU(n) = AEMS_CPU_raw(n) ÷ 4
Edge-EMS Builder-Speicher(n) = Speichersumme der 5 Dienste bei derselben sample_no

Der Bericht muss mindestens Mittelwert, P95, P99 und Spitzenwert angeben. Die unabhängigen Spitzenwerte der fünf Dienste, die zu unterschiedlichen Zeitpunkten auftreten, dürfen nicht direkt addiert werden.

4.3 Trigger und MQTT

Nach aufsteigender zeitlicher Sortierung von trigger_per_sec und mqtt_per_sec werden ebenfalls der erste und letzte Sekunden-Bucket entfernt, um unvollständige Sekunden an den Grenzen des Datenbankabfragezeitraums auszuschließen.

Die Sekunden-Buckets der Aufgaben entsprechen nicht zwingend eins zu eins den Ressourcenmessungen. In einer Sekunde können Einträge fehlen oder aufgestaute Aufgaben erst in der nächsten Sekunde gebündelt abgeschlossen werden. Der Bericht muss die Anzahl gültiger Sekunden-Buckets und folgende Kennzahlen ausweisen:

Mittlere Verarbeitungsmenge pro Sekunde und Zielerreichungsquote;
Mittelwert, P50, P95 und P99 der sekundenweisen mittleren SpendTime;
Höchste einzelne SpendTime über alle Sekunden-Buckets;
Anzahl und Anteil der Sekunden, in denen die mittlere SpendTime 200 ms überschreitet.

Enthält eine vollständige Sekunde keine Aufgabeneinträge, ist ihr Durchsatz als 0 zu werten. Für diese Sekunde lässt sich keine Latenz berechnen; sie darf nicht künstlich mit 0 ms angesetzt werden. Künftige Überwachungsskripte sollten Beginn und Ende des Auswertungsfensters ausdrücklich ausgeben, damit leere Sekunden ergänzt werden können.

5. Zu beobachtende Kennzahlen

Kategorie	Zu erfassende Werte
Datenerfassung	Konfigurierte, erfolgreich erfasste, fehlgeschlagene und verworfene Datenpunkte
Trigger	Soll- und Ist-Anzahl, mittlere Dauer, P50, P95, P99, Maximum
MQTT / Koordination	Soll- und Ist-Anzahl, Dauer, Fehler
CPU	Mittelwert, P95 und Spitzenwert für EMS Builder insgesamt
Arbeitsspeicher	Mittelwert, Spitzenwert und Verlauf für EMS Builder insgesamt
Datenträger	Lese-/Schreibrate, I/O-Wartezeit, Datenbank-Schreibstatus
Modbus	Lese- und Schreibanzahl, Fehler, Zeitüberschreitungen und Wiederholungen je Slave
Stabilität	Abstürze, OOM-Ereignisse, unerwartete Neustarts, anhaltende Rückstaus

Wesentliche Berechnungen:

Korrektheitsquote = Erfolge ÷ (Erfolge + Fehler + Zeitüberschreitungen + verworfene Vorgänge)

Zielerreichungsquote = tatsächliche mittlere Verarbeitungsmenge pro Sekunde ÷ Szenarioziel

SpendTime bezeichnet die tatsächliche Ausführungsdauer einer Aufgabe. Der Bericht darf nicht nur den Mittelwert zeigen, sondern muss auch P95, P99 und Maximum ausweisen, um sporadisch auftretende lange Verzögerungen sichtbar zu machen.

6. Ergebnisbewertung

Projektvertrag und Abnahmespezifikationen haben Vorrang. Ohne gesonderte Vereinbarung gelten die folgenden Referenzwerte.

Kriterium	Empfohlener Richtwert
Verarbeitungsmenge	Mittlere Zielerreichung ≥ 99 %
Trigger-/MQTT-Dauer	P95 < 200 ms
CPU	Mittlere Auslastung eines 4-Kern-Geräts < 80 %, keine anhaltende Volllast
Arbeitsspeicher	Mittlere Gesamtsystem-Auslastung < 70 %, kein kontinuierlicher Anstieg
Korrektheitsquote	≥ 99,99 %, keine ungeklärten verworfenen Vorgänge
Stabilität	72 Stunden ohne Absturz, OOM-Ereignis oder unerwarteten Neustart
Erholungsfähigkeit	Stabilisierung innerhalb von 5 Minuten nach Lastreduzierung

6.1 Bedingungen für ungültige Tests

Situation	Maßnahme
Testdauer zu kurz	Als „nicht abgeschlossen“ kennzeichnen
Nicht alle 20 Slaves beteiligt	Test wiederholen
Schreibvorgänge auf wenige Slaves konzentriert	Verteilung korrigieren und erneut testen
Lastgenerator oder Netzwerk ist der Engpass	Problem beheben und erneut testen
Daten zu Erfolgen, Fehlern oder Zeitüberschreitungen fehlen	Als „unvollständige Daten“ kennzeichnen
S6 nicht 72 Stunden ausgeführt	Nicht als „Stabilitätstest bestanden“ bewerten

S4 und S5 sind Belastungstests. Wird die Systemgrenze erreicht, ist das Ergebnis als „Belastungsgrenze erreicht“ oder „Dauerbetrieb nicht empfohlen“ zu kennzeichnen. Es darf nicht als bestandener regulärer Kapazitätstest dargestellt werden.

Modellspezifische Berichte:

Weiterführende Informationen: