Leistungstestbericht: EMS Builder auf dem AFE-E630
Berichtsversion: v1.3
Testdatum: 2026-07-29
Berichtsdatum: 2026-07-30
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 Datenerfassungslast
Aggregationsberechnungen
Trigger-Zielrate
MQTT-Aufgaben-Zielrate
Koordinationsaufgaben
Spätestens alle 10 Sekunden
Gesamtsystem-CPU: Mittelwert / P95
Gesamtsystem-RAM: Mittelwert / P95
Trigger P95
MQTT P95
Jede Trigger-Ausführung umfasst eine Gerätesteuerung, eine lokale Warnung mit MQTT-Warnung sowie einen Schreibvorgang für Aggregationsdaten. Edge-EMS Builder weist PostgreSQL Ressourcen entsprechend dem Gerätespeicher zu. Der Speicherverbrauch kann sich daher je nach Gerät, Datenbankgröße und Cache-Zustand deutlich unterscheiden.
1.1 Zentrales Ergebnis
Abschnitt betitelt „1.1 Zentrales Ergebnis“Für den AFE-E630 wird der Betrieb nach Szenario S3.5 empfohlen: 5.000 Datenpunkte/s, 30 Aggregationsberechnungen, 90 Trigger/s, 20 MQTT-Aufgaben/s und 10 Koordinationsaufgaben/s mit aktivierter Speicherung bei Änderungen im 10-Sekunden-Intervall.
In S3.5 wurden 89,97 Trigger/s und 19,98 MQTT-Aufgaben/s gemessen. Die P95-Latenzen von Trigger und MQTT betrugen 56 ms bzw. 77 ms. Das CPU-P95 des Gesamtsystems lag bei 71,09 %, das P95 der tatsächlichen Gesamtsystem-Speichernutzung bei 41,41 %. In diesem Szenario traten keine Zeitüberschreitungen bei der Messwerterfassung auf.
Für den langfristigen Produktionsbetrieb wird eine technische Reserve von etwa 20 % gegenüber der gemessenen S3.5-Last empfohlen. Die anfängliche Kapazität kann mit höchstens etwa 4.000 Datenpunkten/s, 72 Triggern/s, 16 MQTT-Aufgaben/s und 8 Koordinationsaufgaben/s geplant werden. Diese Empfehlung ist eine technische Ableitung aus der gemessenen Konfiguration und kein separat durchgeführtes Testszenario. Vor der Inbetriebnahme sind erneute Tests mit den tatsächlichen Projektskripten, Nachrichtengrößen und historischen Datenbankbeständen erforderlich.
1.2 Bewertung der Szenarien
Abschnitt betitelt „1.2 Bewertung der Szenarien“| Symbol | Szenario | Ergebnis |
|---|---|---|
| 🟢 | S1 | Basisszenario bestanden; ausreichende Reserven bei Ressourcen und Aufgabenlatenz. |
| 🟢 | S2 | Bestanden; stabiler Betrieb mit 2.000 Datenpunkten/s bei Echtzeitspeicherung. Eine Zeitüberschreitung bei der Messwerterfassung. |
| 🟢 | S2.5 | Bestanden; Speicherung bei Änderungen senkt die CPU-Last gegenüber S2 deutlich. Keine Zeitüberschreitungen bei der Messwerterfassung. |
| 🟡 | S3 | Aufgabenkennzahlen erfüllen die Anforderungen, das Gesamtsystem-CPU-P95 von 81,06 % liegt jedoch nahe der Dauerbetriebsgrenze. Zwei Zeitüberschreitungen bei der Messwerterfassung. |
| 🟢 | S3.5 | Bestes Gesamtergebnis; derzeit empfohlenes Szenario für den AFE-E630. |
| 🔴 | S6 | Nur als kurzer Vorab-Belastungstest geeignet. Gesamtsystem-CPU-P95: 94,02 %; MQTT-Verarbeitungsmenge unter der empfohlenen 99-%-Marke; elf Zeitüberschreitungen bei der Messwerterfassung. |
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.
- Bei einer konfigurierten Last von 5.000 Datenpunkten/s erreicht S3.5 die Trigger-Zielrate zu 99,97 % und die MQTT-Zielrate zu 99,90 %. Die P95-Latenzen von Trigger und MQTT liegen bei 56 ms bzw. 77 ms.
- S3 und S3.5 haben dieselbe fachliche Last. Durch die Speicherung bei Änderungen sinken in S3.5 der CPU-Mittelwert des Gesamtsystems von 57,95 % auf 50,16 % und das P95 von 81,06 % auf 71,09 %. Dies eignet sich besser für den Dauerbetrieb.
- S6 erreicht die Trigger-Zielrate zu 99,49 %, die MQTT-Zielrate jedoch nur zu 98,73 %. Das Gesamtsystem-CPU-P95 liegt bei 94,02 %, die Spitze bei 100 %. Diese Konfiguration wird nicht für den dauerhaften Produktionsbetrieb empfohlen.
- Das Gesamt-P99 der Trigger-Latenz liegt in allen Szenarien unter 200 ms. Dennoch treten einzelne Ausreißer von etwa 10–12 Sekunden auf. Das MQTT-P99 in S6 liegt mit 236,62 ms bereits über 200 ms.
- 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. Der AFE-E630 besitzt vier Kerne. Daher gilt: „4-Kern-äquivalente CPU-Auslastung von Edge-EMS Builder“ = CPU-Summe der fünf Dienste ÷ 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.
- Die „tatsächliche Gesamtsystem-Speichernutzung“ wird als
MemTotal - MemAvailableberechnet. Sie ist die wichtigste Kennzahl zur Beurteilung der verbleibenden physischen Speicherkapazität. - 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-E630 |
| CPU | Arm Cortex-A55, 4 Kerne |
| Arbeitsspeicher | 3,81 GB DDR4 |
| Betriebssystem | JelinaOS, basierend auf Debian 11 |
| Massenspeicher | eMMC |
| Softwareversionen | CommBridge-rc-2026-07-08T17-52-07; EMS Builder v1.2; PostgreSQL v18.3 |
| Netzwerk | LAN; MQTT / TCP |
| Überwachungsstichproben | Eine Erfassung pro Sekunde; 2.002 pro Szenario, ausgewertet werden die mittleren 2.000 |
| Testdatenquellen | 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. 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. Die Arbeitsmappen enthalten keine Anzahl erfolgreich erfasster Einzelpunkte. Die Konfigurationswerte dürfen daher nicht als unabhängig verifizierter Durchsatz erfolgreicher Datenbankeinträge dargestellt werden.
6. Testzeiträume
Abschnitt betitelt „6. Testzeiträume“| Szenario | Gültiger Auswertungszeitraum | Gültige Dauer |
|---|---|---|
| S1 | 2026-07-29 17:18:09 bis 17:51:29 | 2.000 Sekunden |
| S2 | 2026-07-29 17:54:29 bis 18:27:49 | 2.000 Sekunden |
| S2.5 | 2026-07-29 18:31:54 bis 19:05:14 | 2.000 Sekunden |
| S3 | 2026-07-29 19:09:20 bis 19:42:40 | 2.000 Sekunden |
| S3.5 | 2026-07-29 19:47:06 bis 20:20:26 | 2.000 Sekunden |
| S6 | 2026-07-29 20:24:47 bis 20:58:07 | 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 | 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 % |
Der Spitzenwert von 208,59 % für Edge-EMS Builder in S6 ist ein Ausreißer in einem einzelnen Messfenster. Dabei überschreitet die summierte CPU-Zeit der fünf Dienste die reguläre Kapazität von vier Kernen. Zusammen mit den elf Zeitüberschreitungen bei der Messwerterfassung deutet dies möglicherweise auf überlappende Messzeiträume oder kurzzeitige Scheduling-Spitzen hin. Der Wert wird nicht als dauerhaft tragbare Ressourcennutzung gewertet.
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 | 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 % |
Die CPU-Auslastung des Gesamtsystems ist in diesem Bericht die maßgebliche Grundlage für die Beurteilung der CPU-Kapazität. Das P95 von S3.5 liegt 9,97 Prozentpunkte unter dem von S3. In S6 überschreitet das P95 90 %; damit fehlt eine ausreichende Reserve für den Dauerbetrieb.
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 | 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%） |
Der den fünf Diensten zugeordnete Speicher umfasst gemeinsam genutzte Seiten und Caches, die den cgroups zugerechnet werden. Er entspricht nicht dem Nettoverbrauch an physischem Speicher. Die tatsächliche Gesamtsystem-Speichernutzung bildet die verbleibende Gerätekapazität besser ab und wird daher zur Szenariobewertung herangezogen. Der anfängliche Datenbankzustand und der Cache-Aufwärmzustand beeinflussen die Ergebnisse. Speicheränderungen dürfen nicht allein aus der Anzahl der Datenpunkte 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 | 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 % |
Dieser Bericht verwendet 99 % als Referenzwert für die Verarbeitungsmenge empfohlener Betriebsszenarien. MQTT in S6 bleibt darunter. Gleichzeitig treten hohe CPU-Auslastung, steigende Latenzen und Zeitüberschreitungen bei der Messwerterfassung auf. Diese Last liegt somit bereits im Belastungsbereich.
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 | 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 |
Die üblichen Perzentile sind niedrig, doch in allen Szenarien treten einzelne extreme Ausreißer von etwa 10–12 Sekunden auf. Sie verändern das P99 kaum, können aber einzelne Steuerungs- oder Warnaufgaben beeinträchtigen und müssen gezielt 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 | 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. Szenariobewertung
Abschnitt betitelt „12. Szenariobewertung“| Szenario | Bewertung | Wesentliche Grundlage |
|---|---|---|
| S1 | Bestanden | Bei Basislast: Gesamtsystem-CPU-P95 38,67 %, Speicher-P95 41,97 %; Zielverarbeitungsmenge erreicht. |
| S2 | Bestanden | Trigger- und MQTT-Zielerreichung jeweils nahe 100 %, ausreichende Ressourcenreserve. Eine Zeitüberschreitung bei der Messwerterfassung ist zu beachten. |
| S2.5 | Bestanden | Zielverarbeitungsmenge erreicht. Speicherung bei Änderungen senkt CPU-Mittelwert und CPU-P95 des Gesamtsystems deutlich gegenüber S2. |
| S3 | Bedingt bestanden | Verarbeitungsmenge und Aufgabenlatenz erfüllen die Anforderungen. Gesamtsystem-CPU-P95: 81,06 %; zwei Zeitüberschreitungen bei der Messwerterfassung; geringe Dauerbetriebsreserve. |
| S3.5 | Empfohlen | Bei 5.000 Datenpunkten/s: Trigger- und MQTT-P95 unter 100 ms, Gesamtsystem-CPU-P95 71,09 %, P95 der tatsächlichen Speichernutzung 41,41 %, keine Zeitüberschreitungen bei der Messwerterfassung. |
| S6 | Dauerbetrieb nicht empfohlen | MQTT-Zielerreichung 98,73 %, MQTT-P99 236,62 ms, Gesamtsystem-CPU-P95 94,02 % und elf Zeitüberschreitungen bei der Messwerterfassung. |
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 Datenerfassungslast: 5.000 Datenpunkte/s;
- Aggregationsberechnungen: 30;
- Reguläre Trigger: 50/s;
- 100-ms-Trigger: 4, entsprechend 40/s;
- Trigger insgesamt: 90/s;
- MQTT: 20/s;
- Koordinationsaufgaben: 10/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.
- Für die Gesamtsystem-CPU wird eine Warnschwelle von 80 % empfohlen. Für den Gesamtsystem-Speicher werden 70 % als Warnschwelle und 80 % als kritische Alarmschwelle empfohlen. PostgreSQL-Cache und Datenbankwachstum sind kontinuierlich zu beobachten.
- Bei erforderlicher Echtzeitspeicherung können die Ergebnisse von S3 als Referenz dienen. Dessen Gesamtsystem-CPU-P95 liegt jedoch bereits über 80 %. Sofern keine zwingende fachliche Anforderung besteht, ist die Speicherung bei Änderungen nach S3.5 vorzuziehen.
- S6 dient ausschließlich kurzen Belastungstests sowie Prüfungen der Ratenbegrenzung oder des Überlastschutzes. Als dauerhafte Produktionslast für den E630 wird es nicht empfohlen.
14. Qualitätswarnungen und ergänzende Tests
Abschnitt betitelt „14. Qualitätswarnungen und ergänzende Tests“- In S2 trat eine Zeitüberschreitung bei der Messwerterfassung auf, in S3 zwei und in S6 elf. In S1, S2.5 und S3.5 wurden keine festgestellt.
- Einen vollständigen Stabilitätstest über 72 Stunden durchführen und Prozessneustarts, OOM-Ereignisse, Fehlerprotokolle, die Änderungsrate des Speicherverbrauchs und das Datenbankwachstum erfassen.
- 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–12 Sekunden mit Aufgaben-IDs, Lua-Skripten, SQL, GC, I/O und Systemprotokollen korrelieren.
- 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 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.
- S3.5 ist die gemessene Konfiguration mit den besten Gesamtkennzahlen dieser Testreihe. Die technische Reserve von 20 % ist eine Empfehlung zur Kapazitätsplanung, kein eigenständig gemessenes Ergebnis.
Weitere Modelle: Testbericht zum AFE-E620.