Leistungstestbericht für EMS Builder auf AFE-E620
Berichtsversion: v1.0
Testzeitraum: 2026-07-30 bis 2026-07-31
Berichtsdatum: 2026-07-31
Auswertungsmethode: 2.002 Erfassungen je Szenario; erste und letzte Stichprobe ausgeschlossen, ausgewertet werden die 2.000 gültigen Ressourcenstichprobensample_no=2～2001.
Zugehöriges Handbuch: Leistungstesthandbuch für Edge-EMS Builder
1. Übersicht der Leistungsergebnisse
Abschnitt betitelt „1. Übersicht der Leistungsergebnisse“Konfigurierte Erfassungslast
Aggregationsberechnungen
Trigger-Zielrate
MQTT-Aufgabenziel
Koordinationsaufgaben
Spätestens alle 10 Sekunden
Gesamtsystem-CPU, Mittelwert / P95
Gesamtsystem-Speicher, Mittelwert / P95
Trigger P95
MQTT P95
Jede Triggerausführung umfasst eine Gerätesteuerung, einen lokalen Alarm und einen MQTT-Alarm sowie einen Aggregationsschreibzugriff. Edge-EMS Builder weist PostgreSQL Ressourcen anhand des Gerätespeichers zu. Deshalb kann die Speicherauslastung je nach Gerät, Datenbankumfang und Cache-Zustand deutlich variieren. Mit nur 982 MB physischem Arbeitsspeicher besitzt AFE-E620 erheblich weniger Reserve als AFE-E630; bei der Kapazitätsplanung hat der Arbeitsspeicher Vorrang.
1.1 Zentrales Ergebnis
Abschnitt betitelt „1.1 Zentrales Ergebnis“Für AFE-E620 wird Szenario S2.5 empfohlen: 2.000 Datenpunkte/s, 20 Aggregationsberechnungen, 40 Trigger/s, 10 MQTT-Aufgaben/s und 2 Koordinationsaufgaben/s mit Speicherung bei Änderungen, spätestens alle 10 Sekunden.
In S2.5 wurden 39,96 Trigger/s und 9,98 MQTT-Aufgaben/s gemessen, entsprechend 99,91 % bzw. 99,82 % Zielerfüllung. Die P95-Latenzen betrugen 25 ms für Trigger und 56 ms für MQTT. Die CPU-Auslastung des Gesamtsystems lag bei P95 45,54 %, die tatsächliche Arbeitsspeicherauslastung bei P95 86,10 %. Es traten 8 Zeitüberschreitungen bei der Stichprobenerfassung auf.
Für langfristigen Produktivbetrieb wird eine technische Reserve von etwa 20 % gegenüber der getesteten S2.5-Last empfohlen. Die erste Planung kann bei höchstens etwa 1.600 Datenpunkten/s, 32 Triggern/s, 8 MQTT-Aufgaben/s und 2 Koordinationsaufgaben/s ansetzen. Dies sind aus der Messkonfiguration abgeleitete Planungswerte, kein separat getestetes Szenario. Vor dem Produktivstart müssen tatsächliche Skripte, Nachrichtengrößen und historische Datenbankmengen erneut getestet werden.
1.2 Bewertung der Szenarien
Abschnitt betitelt „1.2 Bewertung der Szenarien“| Symbol | Szenario | Ergebnis |
|---|---|---|
| 🟢 | S1 | Basisszenario bestanden, Zielerfüllung 100 %; die mittlere Arbeitsspeicherauslastung liegt jedoch bereits bei 74,02 % und damit auf hohem Grundniveau. |
| 🟡 | S2 | Bei Echtzeitspeicherung erreichen Trigger/MQTT 98,65 % / 98,76 %, knapp unter der 99-%-Referenz; 34 Zeitüberschreitungen bei der Stichprobenerfassung. |
| 🟢 | S2.5 | Höchste Last mit mindestens 99 % Zielerfüllung; aktuell empfohlenes Szenario für AFE-E620. |
| 🔴 | S3 | Nicht bestanden: Trigger/MQTT erreichen nur 43,08 % / 44,65 %, stark erhöhte Latenzen und 617 Zeitüberschreitungen bei der Stichprobenerfassung. |
| 🔴 | S3.5 | Nicht bestanden: Speicherung bei Änderungen verbessert S3 deutlich, aber 87,30 % / 86,69 % Zielerfüllung bleiben unter 99 %. |
| 🔴 | S6 | Starke Überlast: Trigger/MQTT erreichen nur 19,15 % / 19,18 %; 886 Zeitüberschreitungen bei der Stichprobenerfassung. |
2. Ergebniszusammenfassung
Abschnitt betitelt „2. Ergebniszusammenfassung“- Getestet wurden S1, S2, S2.5, S3, S3.5 und S6. Andere Szenarien sind nicht Bestandteil der Datentabellen, Vergleiche oder Schlussfolgerungen.
- S2.5 erreicht bei konfigurierten 2.000 Datenpunkten/s eine Zielerfüllung von 99,91 % für Trigger und 99,82 % für MQTT. Die P95-Latenzen betragen 25 ms bzw. 56 ms.
- S2 und S2.5 verwenden dieselbe fachliche Last. Durch Speicherung bei Änderungen sinkt in S2.5 die mittlere Gesamtsystem-CPU-Auslastung von 29,41 % auf 26,24 % und P95 von 52,01 % auf 45,54 %. Die Trigger-Zielerfüllung steigt von 98,65 % auf 99,91 %.
- S3 und S3.5 verwenden dieselbe fachliche Last. Speicherung bei Änderungen erhöht die Trigger-Zielerfüllung von 43,08 % auf 87,30 % und MQTT von 44,65 % auf 86,69 %. Die CPU-Auslastung des Gesamtsystems sinkt bei P95 von 82,71 % auf 66,05 %. Dennoch wird das Kriterium nicht erreicht: 5.000 Datenpunkte/s überschreiten die dauerhafte Kapazität von AFE-E620.
- Vergleich mit AFE-E630: E630 bewältigt S3.5 mit 5.000 Datenpunkten/s und 90 Triggern/s. Die validierte Grenze von E620 liegt bei S2.5 mit 2.000 Datenpunkten/s und 40 Triggern/s. Der Unterschied beim Arbeitsspeicher – 3,81 GB gegenüber 982 MB – ist der wesentliche Einflussfaktor.
- In allen Szenarien treten einzelne Trigger-Latenzspitzen von etwa 10–11 Sekunden auf. Unter Überlast nehmen sie weiter zu: In S3.5 erreicht ein Trigger maximal 53.472 ms, ein MQTT-Vorgang 53.373 ms.
- Die mittlere Arbeitsspeicherauslastung des Gesamtsystems übersteigt in allen Szenarien 74 %. Ab S3 liegt P95 über 91 %. Arbeitsspeicher ist in sämtlichen E620-Szenarien ein gemeinsamer Engpass und muss kontinuierlich überwacht werden.
- Pro Szenario wurden nur 2.000 Sekunden gültiger Stichproben ausgewertet, etwa 33 Minuten und 20 Sekunden. Das eignet sich für Leistungsvergleiche, ersetzt jedoch keinen 72-Stunden-Stabilitätstest.
3. Auswertungsmethode
Abschnitt betitelt „3. Auswertungsmethode“3.1 Stichprobenauswahl
Abschnitt betitelt „3.1 Stichprobenauswahl“Die Überwachung zählt Erfassungen. Die Rohdaten jedes Szenarios enthalten sample_no=1～2002:
Auslassen: sample_no = 1Auswerten: sample_no = 2–2001, insgesamt 2.000 MessungenAuslassen: sample_no = 2002Das Ausschließen der ersten und letzten Stichprobe verhindert, dass unvollständige Sekunden zu Beginn und Ende in die Statistik eingehen. Gesamtergebnisse von Trigger und MQTT verwenden 2.000 Sekunden als Nenner. Auch Sekunden ohne Aufgaben werden in den mittleren Durchsatz einbezogen, damit die Auswertung nicht durch ausschließliche Berücksichtigung aktiver Sekunden überschätzt wird.
3.2 Gesamtumfang von EMS Builder
Abschnitt betitelt „3.2 Gesamtumfang von EMS Builder“Die folgenden fünf Dienste werden gemeinsam als vollständiges Edge-EMS Builder betrachtet:
| Dienst | Aufgabe |
|---|---|
cb_core |
Datenerfassung und Kernkommunikation |
cb_nginx |
CommBridge-Weboberfläche / Reverse-Proxy |
cb_backend |
CommBridge-Backend |
ems_backend |
Berechnung, Strategien und Fachlogik von EMS Builder |
ems_postgresql |
Datenspeicherung von EMS Builder |
Für jedes sample_no werden zuerst die fünf Dienste summiert. Aus den 2.000 Summenwerten werden Mittelwert, P95, P99 und Maximum berechnet. Einzelne Dienstmaxima zu unterschiedlichen Zeitpunkten werden nicht direkt addiert.
3.3 CPU, Arbeitsspeicher und Aufgabenlatenz
Abschnitt betitelt „3.3 CPU, Arbeitsspeicher und Aufgabenlatenz“- Die CPU-Rohwerte der fünf Dienste sind einkernäquivalente Prozentwerte. AFE-E620 besitzt vier Kerne; die „4-Kern-äquivalente CPU-Auslastung von Edge-EMS Builder“ entspricht daher der Summe der fünf Dienste geteilt durch 4.
- „Gesamtsystem-CPU“ verwendet
_system_totalaus der Arbeitsmappe. Der Wert ist auf die gesamte CPU-Kapazität von 0–100 % normiert und dient als Hauptindikator zur Kapazitätsbewertung. - „Edge-EMS Builder zugeordneter Speicher“ summiert den cgroup-zugeordneten Speicher der fünf Dienste. Gemeinsam genutzte Seiten und Caches können mehrfach zugeordnet sein. Der Wert kann deshalb den tatsächlich genutzten Gesamtspeicher übersteigen und darf nicht einfach durch den physischen Speicher geteilt werden, um die Kapazitätsauslastung zu bestimmen.
- „Tatsächlicher Gesamtsystemspeicher“ wird als
MemTotal - MemAvailableberechnet und ist der Hauptindikator für die physische Speicherreserve. Speicherprozente dieses Berichts beziehen sich auf MemTotal = 982 MB. - Mittelwert sowie P50, P95 und P99 von Trigger/MQTT basieren auf sämtlichen Aufgabenaufzeichnungen im gültigen Zeitraum, nicht auf Quantilen sekündlicher Mittelwerte.
- Alle Arbeitsmappen bestanden die Prüfung, dass die Testlast vor der Zusammenfassung beendet war. Trigger, MQTT und CommBridge wurden zuvor gestoppt; anschließend wurde 30 Sekunden gewartet.
4. Testgerät und Umgebung
Abschnitt betitelt „4. Testgerät und Umgebung“| Merkmal | Konfiguration |
|---|---|
| Gerätemodell | AFE-E620 |
| CPU | Arm Cortex-A55, 4 Kerne |
| Arbeitsspeicher | 982 MB DDR3 |
| Betriebssystem | JelinaOS auf Basis von Ubuntu 20.04 |
| Massenspeicher | eMMC |
| Softwareversion | Noch zu ergänzen; die Arbeitsmappen dieser Serie enthalten keine Versionen. CommBridge-, EMS Builder- und PostgreSQL-Version sind vor der Archivierung nachzutragen. |
| Netzwerk | LAN; MQTT / TCP |
| Überwachungsstichproben | Eine Erfassung pro Sekunde; 2.002 pro Szenario, ausgewertet werden die mittleren 2.000 |
| Testdatenquellen | 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. Szenarien und Lasten
Abschnitt betitelt „5. Szenarien und Lasten“| Szenario | Datenerfassung | Aggregationen | Normale Trigger | 100-ms-Trigger | Trigger-Zielrate | MQTT-Zielrate | Koordinationsaufgaben | Speicherstrategie |
|---|---|---|---|---|---|---|---|---|
| S1 | 500 Datenpunkte/s | 10 | 10/s | 0 | 10/s | 5/s | 0/s | Echtzeit |
| S2 | 2.000 Datenpunkte/s | 20 | 20/s | 2 | 40/s | 10/s | 2/s | Echtzeit |
| S2.5 | 2.000 Datenpunkte/s | 20 | 20/s | 2 | 40/s | 10/s | 2/s | Bei Änderungen (10 s) |
| S3 | 5.000 Datenpunkte/s | 30 | 50/s | 4 | 90/s | 20/s | 10/s | Echtzeit |
| S3.5 | 5.000 Datenpunkte/s | 30 | 50/s | 4 | 90/s | 20/s | 10/s | Bei Änderungen (10 s) |
| S6 | 5.000 Datenpunkte/s | 20 | 50/s | 10 | 150/s | 30/s | 15/s | Echtzeit |
„Datenerfassung“ bezeichnet die konfigurierte Szenariolast gemäß Testhandbuch. Die Arbeitsmappen enthalten weder Erfolgszahlen je Datenpunkt noch detaillierte Szenariokonfigurationen. Konfigurationswerte dürfen daher nicht als unabhängig validierter Durchsatz erfolgreicher Datenbankschreibungen bezeichnet werden. Die Trigger-/MQTT-Zielwerte entsprechen den Zielwerten der Erfüllungsprüfung in den Arbeitsmappen.
6. Testzeiträume
Abschnitt betitelt „6. Testzeiträume“| Szenario | Gültiger Auswertungszeitraum | Gültige Dauer |
|---|---|---|
| S1 | 2026-07-30 10:13:55 bis 10:47:13 | 2.000 Sekunden |
| S2 | 2026-07-30 10:51:30 bis 11:24:48 | 2.000 Sekunden |
| S2.5 | 2026-07-30 11:30:33 bis 12:03:51 | 2.000 Sekunden |
| S3 | 2026-07-30 15:25:51 bis 15:59:09 | 2.000 Sekunden |
| S3.5 | 2026-07-31 12:23:59 bis 12:57:17 | 2.000 Sekunden |
| S6 | 2026-07-31 17:36:29 bis 18:09:47 | 2.000 Sekunden |
Alle Zeitangaben verwenden UTC+8.
7. CPU-Ergebnisse
Abschnitt betitelt „7. CPU-Ergebnisse“7.1 Summe der fünf EMS Builder-Dienste (4-Kern-Äquivalent)
Abschnitt betitelt „7.1 Summe der fünf EMS Builder-Dienste (4-Kern-Äquivalent)“| Status | Szenario | Mittelwert | P95 | P99 | Maximum |
|---|---|---|---|---|---|
| 🟢 | 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 % |
Die Edge-EMS Builder-Spitzenwerte von S2, S3 und S3.5 betragen 110,22 %, 115,84 % und 130,65 %. Es handelt sich um Momentanwerte einzelner Stichprobenfenster, in denen die summierte CPU-Zeit der fünf Dienste die übliche Vierkernkapazität übersteigt. Beispielsweise erreicht ems_backend in S2 als einzelner Dienst in einer Stichprobe 402 %. Zusammen mit den Erfassungszeitüberschreitungen deutet dies möglicherweise auf periodenübergreifende Stichprobenfenster oder kurzfristige Scheduling-Spitzen hin. Die Werte gelten nicht als dauerhafte Ressourcenauslastung.
7.2 CPU des Gesamtsystems, auf die gesamte Kapazität normiert
Abschnitt betitelt „7.2 CPU des Gesamtsystems, auf die gesamte Kapazität normiert“| Status | Szenario | Mittelwert | P95 | P99 | Maximum |
|---|---|---|---|---|---|
| 🟢 | 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 % |
Die Gesamtsystem-CPU ist die Hauptgrundlage zur CPU-Kapazitätsbewertung. P95 liegt in S2.5 um 6,47 Prozentpunkte unter S2. Ab S3 übersteigt P95 in allen Szenarien 66 %, während Spitzen 100 % erreichen; die CPU gerät in Sättigung.
8. Arbeitsspeicherergebnisse
Abschnitt betitelt „8. Arbeitsspeicherergebnisse“| Status | Szenario | EMS Builder zugeordneter Speicher, Mittelwert | EMS Builder zugeordneter Speicher, P95 | Tatsächlicher Gesamtspeicher, Mittelwert | Tatsächlicher Gesamtspeicher, P95 | Tatsächlicher Gesamtspeicher, Maximum |
|---|---|---|---|---|---|---|
| 🟢 | 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%） |
Der den fünf Diensten zugeordnete Speicher enthält cgroup-zugeordnete gemeinsame Seiten und Caches und entspricht nicht der physischen Nettobelegung. Der tatsächliche Gesamtsystemspeicher bildet die verbleibende Gerätekapazität besser ab und wird deshalb zur Szenariobewertung verwendet. AFE-E620 besitzt nur 982 MB physischen Speicher. Bereits S1 erreicht im Mittel 74,02 %, sodass Betriebssystem und Edge-EMS Builder dauerhaft fast drei Viertel der Kapazität belegen. Ab S3 liegt P95 über 91 %; weniger als 90 MB bleiben verfügbar, und Speicherdruck entsteht. Datenbank-Ausgangszustand und Cache-Aufwärmung beeinflussen die Ergebnisse. Speicheränderungen dürfen nicht allein aus der Datenpunktzahl abgeleitet werden.
9. Durchsatzergebnisse
Abschnitt betitelt „9. Durchsatzergebnisse“Der mittlere Durchsatz verwendet den vollständigen gültigen Zeitraum von 2.000 Sekunden als Nenner. Die Zielerfüllung wird aus Gesamtaufgabenzahl geteilt durch Gesamtzielzahl berechnet, um Rundungsabweichungen angezeigter Arbeitsmappenwerte zu vermeiden.
| Status | Szenario | Trigger gesamt | Trigger Mittelwert / Ziel | Trigger-Zielerfüllung | MQTT gesamt | MQTT Mittelwert / Ziel | MQTT-Zielerfüllung |
|---|---|---|---|---|---|---|---|
| 🟢 | 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 % |
Dieser Bericht verwendet 99 % als Durchsatzreferenz für empfohlene Betriebsszenarien. S2 liegt knapp darunter. In S3, S3.5 und S6 reicht die Verarbeitungskapazität deutlich nicht aus. Unter Überlast wächst die Aufgabenwarteschlange kontinuierlich, und die tatsächlichen Abschlüsse bleiben weit unter dem Ziel.
10. Triggerlatenz
Abschnitt betitelt „10. Triggerlatenz“Die folgenden Quantile basieren auf allen Triggeraufzeichnungen im gültigen Zeitraum. Einheit: Millisekunden.
| Status | Szenario | Mittelwert | P50 | P95 | P99 | Größter Einzelwert |
|---|---|---|---|---|---|---|
| 🟢 | 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 |
Bis einschließlich S2.5 sind die üblichen Quantile niedrig. Dennoch treten in allen Szenarien einzelne extreme Latenzspitzen von etwa 10–11 Sekunden auf. Unter Überlast erhöhen diese den Mittelwert stark: In S3.5 liegt der Mittelwert beispielsweise bei 76,65 ms und damit über P95 von 58 ms, während P50 nur 13 ms beträgt. Für das typische Verhalten sind daher P50/P95 vorrangig. Die seltenen Spitzen verändern P99 kaum, können jedoch einzelne Steuer- oder Alarmaufgaben beeinträchtigen und müssen gesondert untersucht werden.
11. MQTT-Latenz
Abschnitt betitelt „11. MQTT-Latenz“Die folgenden Quantile basieren auf allen MQTT-Aufzeichnungen im gültigen Zeitraum. Einheit: Millisekunden.
| Status | Szenario | Mittelwert | P50 | P95 | P99 | Größter Einzelwert |
|---|---|---|---|---|---|---|
| 🟢 | 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. Szenariobewertung
Abschnitt betitelt „12. Szenariobewertung“| Szenario | Bewertung | Wesentliche Grundlage |
|---|---|---|
| S1 | Bestanden | Trigger und MQTT erreichen bei Basislast 100 %; Gesamtsystem-CPU P95 26,83 %. Die mittlere Arbeitsspeicherauslastung liegt jedoch bereits bei 74,02 %. |
| S2 | Bedingt bestanden | Noch ausreichende Ressourcenreserve bei Gesamtsystem-CPU P95 52,01 %, aber Trigger/MQTT mit 98,65 % / 98,76 % knapp unter 99 %; 34 Erfassungszeitüberschreitungen. |
| S2.5 | Empfohlen | Bei 2.000 Datenpunkten/s erreichen Trigger/MQTT 99,91 % / 99,82 %; P95 beträgt 25 ms / 56 ms, Gesamtsystem-CPU P95 45,54 %. Höchste Last, die den Referenzwert erreicht. |
| S3 | Nicht bestanden | Trigger/MQTT nur 43,08 % / 44,65 %, MQTT P99 944,41 ms, Gesamtsystem-CPU P95 82,71 %, Speicher P95 94,80 % und 617 Erfassungszeitüberschreitungen. |
| S3.5 | Nicht bestanden | Speicherung bei Änderungen verbessert S3 deutlich: CPU P95 66,05 %, Trigger P95 58 ms. Zielerfüllung von 87,30 % / 86,69 % bleibt jedoch zu niedrig; 96 Erfassungszeitüberschreitungen. |
| S6 | Für keinen Produktiveinsatz empfohlen | Zielerfüllung nur 19,15 % / 19,18 %, Gesamtsystem-CPU P95 88,33 %, Speicher P95 94,92 % und 886 Erfassungszeitüberschreitungen. Das Gerät ist stark überlastet. |
13. Kapazitäts- und Bereitstellungsempfehlungen
Abschnitt betitelt „13. Kapazitäts- und Bereitstellungsempfehlungen“13.1 Validierte empfohlene Konfiguration
Abschnitt betitelt „13.1 Validierte empfohlene Konfiguration“- Konfigurierte Datenerfassung: 2.000 Datenpunkte/s;
- Aggregationsberechnungen: 20;
- Normale Trigger: 20/s;
- 100-ms-Trigger: 2, entsprechend 20 Ausführungen/s;
- Trigger insgesamt: 40/s;
- MQTT: 10/s;
- Koordinationsaufgaben: 2/s;
- Triggeraufzeichnungen: speichern;
- Datenspeicherung: bei Änderungen, bei unverändertem Wert spätestens alle 10 Sekunden.
13.2 Empfehlungen für den Produktiveinsatz
Abschnitt betitelt „13.2 Empfehlungen für den Produktiveinsatz“- Für Dauerbetrieb etwa 20 % technische Reserve gegenüber der getesteten Konfiguration vorsehen. Vor dem Produktivstart mit tatsächlichen Lua-Skripten, Nachrichtengrößen und historischen Datenmengen erneut testen.
- AFE-E620 besitzt eine hohe Speicherausgangslast; bereits das Basisszenario S1 liegt im Mittel über 74 %. Empfohlen werden eine CPU-Warnung bei 80 %, eine Speicherwarnung bei 85 % und ein kritischer Speicheralarm bei 90 %. PostgreSQL-Cache und Datenbankwachstum kontinuierlich beobachten; bei Bedarf geringere PostgreSQL-Speicherzuteilung oder ein größeres Gerätemodell prüfen.
- Bei erforderlicher Echtzeitspeicherung kann S2 als Referenz dienen, liegt jedoch knapp unter 99 % Zielerfüllung. Ohne zwingende fachliche Anforderung ist die änderungsbasierte Speicherung von S2.5 vorzuziehen.
- S3 (5.000 Datenpunkte/s) und höhere Lasten überschreiten die Dauerbelastbarkeit des AFE-E620. Auch mit Speicherung bei Änderungen (S3.5) wurde der Test nicht bestanden. Für diesen Kapazitätsbedarf sollte der AFE-E630 eingesetzt werden.
- S6 überlastet den E620 bereits stark und liefert keine brauchbare Grundlage für einen vorläufigen Belastungstest. Für die Prüfung des Überlastschutzes wird ein kurzer Test mit einer Last in der Größenordnung von S3 empfohlen.
14. Qualitätswarnungen und ergänzende Tests
Abschnitt betitelt „14. Qualitätswarnungen und ergänzende Tests“- Zeitüberschreitungen bei der Messwerterfassung: 3 in S1, 34 in S2, 8 in S2.5, 617 in S3, 96 in S3.5 und 886 in S6. In Überlastszenarien kann auch die Überwachung selbst ihre Messungen nicht rechtzeitig abschließen. Die Ressourcendaten dieser Szenarien sind daher weniger verlässlich; die Bewertung stützt sich vor allem auf Verarbeitungsmenge und Latenz.
- Die Softwareversionen von CommBridge, Edge-EMS Builder und PostgreSQL für diese Testreihe nachtragen, um die Angaben zur Testumgebung zu vervollständigen.
- Einen vollständigen Stabilitätstest über 72 Stunden durchführen und Prozessneustarts, OOM-Ereignisse, Fehlerprotokolle, die Änderungsrate des Speicherverbrauchs und das Datenbankwachstum erfassen. Wegen der hohen Grundauslastung des E620-Arbeitsspeichers ist insbesondere auf einen langsamen Anstieg des Speicherverbrauchs zu achten.
- Für Datenerfassungspunkte, Trigger, MQTT und Koordinationsaufgaben jeweils Zähler für erfolgreiche, fehlgeschlagene, abgelaufene und verworfene Vorgänge ergänzen.
- Datenträgerdurchsatz, I/O-Wartezeit, PostgreSQL-WAL und Checkpoints, Verbindungspools sowie Warteschlangentiefen ergänzen.
- Einzelne Trigger-Ausreißer von 10–11 Sekunden sowie die in S3.5 gleichzeitig bei Trigger und MQTT aufgetretenen Extremwerte von etwa 53 Sekunden anhand von Aufgaben-IDs, Lua-Skripten, SQL, GC, I/O und Systemprotokollen untersuchen.
- Vor Beginn jedes Szenarios Datenbankgröße, PostgreSQL-Konfiguration und Cache-Aufwärmzustand erfassen, um die Speicherergebnisse der Szenarien besser vergleichen zu können.
15. Einschränkungen der Daten
Abschnitt betitelt „15. Einschränkungen der Daten“- Die Anzahl der Datenpunkte ist eine Testkonfiguration und keine Zählung erfolgreich verarbeiteter Einzelpunkte. Die vorhandenen Daten belegen nicht unabhängig, dass jeder Erfassungspunkt erfolgreich gespeichert wurde.
- Die fachliche Konfiguration der Szenarien (Anzahl der Aggregationen, Zusammensetzung der Trigger und Anzahl der Koordinationsaufgaben) folgt dem Testhandbuch. Die Arbeitsmappen enthalten keine detaillierten Konfigurationen je Szenario.
- Die Arbeitsmappen enthalten keine Felder für fachliche Fehlerraten, Aufgabenergebnisse oder Korrektheitsquoten. Das Erreichen der Zielverarbeitungsmenge bedeutet keine fachliche Korrektheit von 100 %.
- Alle Szenarien dieser Reihe sind Kurztests von etwa 33 Minuten und 20 Sekunden. Sie eignen sich für Leistungsvergleiche, ersetzen aber keinen Langzeitstabilitätstest.
- Die Softwareversionen dieser Testreihe wurden nicht in den Arbeitsmappen erfasst. Die Zuordnung der Ergebnisse zu den Versionen muss nach dem Nachtragen bestätigt werden.
- S2.5 ist die höchste in dieser Testreihe geprüfte Lastkonfiguration, die den Referenzwert von 99 % für die Verarbeitungsmenge erreicht. Die technische Reserve von 20 % ist eine Empfehlung zur Kapazitätsplanung, kein eigenständig gemessenes Ergebnis.
Weitere Modelle: Testbericht zum AFE-E630.