ERP wird langsam: Ursachen systematisch eingrenzen

Wenn eine Maske erst nach Sekunden erscheint oder ein Bericht länger läuft als geplant, hilft eine Messung statt eines Verdachts. Die folgende Reihenfolge teilt die Gesamtdauer in fünf Zweige und liefert je Zweig einen Wert, den Sie mit derselben Aktion an einem ruhigen Tag vergleichen.

Was Sie vorab brauchen

• die betroffene Aktion mit Rolle und Gerät: Maske, Bericht, Lauf einer Schnittstelle oder Druckvorgang
• den Bezugswert derselben Aktion aus einem unauffälligen Tag und einen Schwellwert, ab dem Sie handeln
• Zugang zu den Protokollen von Arbeitsplatz, Anwendungsserver und Datenbankserver
• die Systemzeiten der beteiligten Systeme samt ihrer Abweichung voneinander
• den Ausführungsplan der betroffenen Abfrage und die Protokolle der Schnittstellen
• eine geplante Änderung, die Sie einzeln testen wollen

Bezugswerte, Schwellwerte und Meldewege gehören in einen Monitoring-Plan; Schwellwerte je IT-Komponente, die eine Meldung auslösen, beschreibt der BSI IT-Grundschutz in der Anforderung OPS.1.1.1.A9.

Der Diagnosebaum: fünf Zweige, fünf Messungen

Die Tabelle nennt je Zweig die Messung und was der Befund eingrenzt. Einen Zweig, den die betroffene Aktion nicht berührt, lassen Sie aus.

Zweig	Messung	Größe und Einheit	Was der Befund eingrenzt
Netzwerk	Rundlaufzeit im Leerlauf und unter Last	Basis-Rundlaufzeit in Millisekunden, TCP-Effizienz in Prozent	Übertragungsweg und Zwischenstellen
Arbeitsplatz	Zeit bis zum Beginn der Antwort und bis zur sichtbaren Maske	Millisekunden aus der Zeitmessung des Browsers bei neuer Dokumentnavigation, sonst Dauer der Anfrage und Stoppuhr	Browser und lokale Rechenleistung; die Spanne ab dem Beginn der Antwort enthält auch die restliche Übertragung und weitere Ressourcen
Anwendung	Dauer der Serveranfrage	Millisekunden je Span	Programmlauf, Sperren, Warteschlange
Datenbank	Ausführungsplan der Aktion	geschätzte Zeilen und Kosten; beim ausgeführten Plan tatsächliche Zeilen und Laufzeit je Knoten in Millisekunden	Abfrage, Statistik, Index
Schnittstellen	Rückstand und Laufzeit je Lauf	Alter der ältesten wartenden Nachricht in Minuten	dass Rückstand entsteht; der Verursacher ist damit noch nicht bestimmt

Schritt für Schritt: vom Symptom zum Zweig

Schritt 1: Symptom, Bezugswert und Schwellwert festhalten

Notieren Sie, welche Aktion betroffen ist, mit welcher Rolle an welchem Gerät sie läuft, zu welcher Uhrzeit und mit welcher Dauer in Sekunden. Prüfen Sie dieselbe Aktion an einem zweiten Arbeitsplatz: Dauert sie dort gleich lang, ist eine gemeinsame Ursache wahrscheinlicher als ein Fehler an einem einzelnen Gerät. Ob diese Ursache im gemeinsamen Netz, in einer gemeinsamen Konfiguration oder am Anwendungsserver liegt, sagt der Vergleich nicht; der Befund ist ein Hinweis, kein Beweis. Notieren Sie die Dauer der Aktion zu einer ruhigen Tageszeit als Bezugswert und legen Sie je Zweig einen Schwellwert fest, ab dem Sie tätig werden. Der IT-Grundschutz verlangt dazu einen vorher festgelegten Monitoring-Plan mit angemessenen Schwellwerten je IT-Komponente; er ist keine Rechtsnorm und bindet nur, soweit Gesetz oder Vertrag auf ihn verweisen. Ende: eine wiederholbare Aktion mit Dauer in Sekunden, Bezugswert und Schwellwert.

Schritt 2: Zeitstempel vergleichbar machen

Vergleichen Sie Uhrzeiten erst, wenn die Uhren der beteiligten Systeme übereinstimmen. Die Anforderung OPS.1.1.5.A4 des IT-Grundschutzes verlangt, dass die Systemzeit aller protokollierenden Systeme und Anwendungen synchron ist und das Datums- und Zeitformat einheitlich. Die Gefährdungslage desselben Bausteins nennt unter der Nummer 2.3 den Grund: Ohne gemeinsame Zeitbasis weisen die Zeitstempel der Ereignisse keine gemeinsame Grundlage auf, und die Protokolldaten lassen sich dann möglicherweise nicht mehr miteinander korrelieren. Die Zeitsynchronisation beschreibt der Baustein OPS.1.2.6 des IT-Grundschutzes: NTP-Clients beziehen Zeitinformationen von NTP-Servern und passen ihre interne Uhr an. Auch die W3C-Spezifikation Server-Timing geht davon aus, dass Browser, Server und Zwischenstellen nicht dieselbe Uhr führen, und überträgt deshalb nur Dauern. Messung: Abweichung der Systemuhr je System in Millisekunden. Ende: alle beteiligten Systeme melden dieselbe Zeit.

Schritt 3: Netzwerk messen

Messen Sie die Rundlaufzeit vom betroffenen Arbeitsplatz zum Anwendungsserver mit einem ICMP-Echo über einen Arbeitstag; das Echo trägt Typ 8, die Antwort Typ 0, und Kennung und Sequenznummer ordnen Antwort und Anfrage einander zu (RFC 792). Notieren Sie den kleinsten Wert. RFC 6349 empfiehlt, die Basis-Rundlaufzeit außerhalb der Spitzenzeit zu messen und den kleinsten Wert als Basis zu nehmen, weil Warteschlangen im Netz die Zeit erhöhen. Für die Lastmessung liefert derselbe Rahmen zwei Kennzahlen: Die TCP-Effizienz ist der Anteil der Bytes, der nicht erneut übertragen werden musste (das Rechenbeispiel in RFC 6349 setzt 100.000 gesendete Bytes an, von denen 2.000 erneut übertragen wurden, also 102.000 übertragene Bytes, und ergibt 98,04 Prozent; der RFC druckt dafür 98,03 Prozent), der Puffer-Verzögerungsanteil ist der Zuwachs der mittleren Rundlaufzeit unter Last gegenüber der Basis. Messung: Basis-Rundlaufzeit in Millisekunden, TCP-Effizienz und Puffer-Verzögerung in Prozent. Ende: je ein Wert für Leerlauf und Last.

Schritt 4: Arbeitsplatz messen

Diese Messung gilt für eine Maske, die als neues Dokument im Browser geladen wird; die W3C-Spezifikation Navigation Timing Level 2, ein Working Draft, erfasst die Navigation eines Dokuments. Sie nennt unter anderem responseStart, den Beginn der Antwort des Servers beim Browser, domContentLoadedEventEnd nach der Behandlung des DOMContentLoaded-Ereignisses und loadEventEnd nach der Behandlung des Lade-Ereignisses; die Werte stehen in Millisekunden. Die Zeit bis responseStart enthält den Weg der Anfrage und die Bearbeitung durch den Anwendungsserver; welchen Anteil davon die Aufzeichnung aus Schritt 5 abdeckt, zeigt der Vergleich dort. Die Zeit von responseStart bis loadEventEnd ist keine reine Arbeitsplatzzeit: Sie reicht bis zum Abschluss der Behandlung des Lade-Ereignisses und enthält damit den restlichen Empfang des Dokuments und das Laden der Ressourcen, die das Dokument einbindet. Sie ist deshalb eine Obergrenze für den Anteil des Arbeitsplatzes und keine Netzwerkzeit. Diese Ressourcen trennen Sie mit der W3C-Spezifikation Resource Timing, die für jede abgerufene Ressource unter anderem responseStart und responseEnd führt. Wechselt die Maske innerhalb derselben Seite ohne neue Dokumentnavigation, liefert Navigation Timing keine Werte; messen Sie dann die Dauer der konkreten Anfrage wie in Schritt 5 und dazu den Zeitpunkt, an dem die Maske sichtbar ist. Für einen installierten Client ohne Browser messen Sie mit einer Stoppuhr vom Tastendruck bis zur sichtbaren Maske und notieren, wann die Antwort des Servers eintrifft. Ende: je Maske ein Wert bis zum Beginn der Antwort und ein Wert bis zur sichtbaren Anzeige.

Schritt 5: Anwendung messen

Lassen Sie dieselbe Aktion serverseitig aufzeichnen. Die Trace-Spezifikation von OpenTelemetry beschreibt einen Span als Aufzeichnung einer Operation mit Zeitstempel und Dauer; die Spezifikation nennt Millisekunden als kleinste und Nanosekunden als größte Genauigkeit. Ein Span je Anfrage liefert die Dauer der Serverseite. Antwortet die Anwendung über HTTP, kann der Server seine Teildauern zusätzlich im Kopf Server-Timing mitschicken; nach der Spezifikation trägt der Parameter dur die Dauer und desc eine Beschreibung, wobei Millisekunden empfohlen, aber nicht erzwungen sind. Vergleichen Sie die Dauer des Spans mit dem Wert bis responseStart aus Schritt 4: Sind beide etwa gleich groß, trägt die Anwendung die Zeit bis zum Beginn der Antwort; ist der Span deutlich kürzer, liegt der Unterschied vor dem Beginn oder nach dem Ende der Aufzeichnung. Messung: Dauer je Span in Millisekunden für dieselbe Aktion. Ende: eine Dauer je Anfrage, über den Tag gesammelt.

Schritt 6: Datenbank messen

Lassen Sie sich für die betroffene Abfrage den Ausführungsplan zeigen. Ein Plan ohne Ausführung nennt nur die geschätzten Zeilen und Kosten. Wird die Abfrage für den Plan tatsächlich ausgeführt, zeigt die Ausgabe je Knoten die geschätzten und die tatsächlich zurückgegebenen Zeilen, die Zeit bis zur ersten Zeile und die Laufzeit in Millisekunden; je nach System stehen am Ende zusätzlich eine Summe für Planung und Ausführung oder eine Option für Pufferzugriffe mit Treffern und Lesezugriffen bereit. Die geschätzten Zeilenzahlen stammen aus Stichproben der Statistik; ein großer Abstand zur tatsächlichen Zeilenzahl weist deshalb auf die Statistik. Nach einer der beiden Dokumentationen in den Quellen gehört das Umformen der Ausgabedaten und das Senden der Ergebnisdaten an den Client nicht zur Laufzeit des obersten Knotens; prüfen Sie das für Ihr System. Die ausgeführte Analyse lässt die Abfrage wirklich laufen, und ihre Nebenwirkungen treten wie sonst ein. Messung: Ausführungszeit der Abfrage in Millisekunden und der Faktor zwischen geschätzten und tatsächlichen Zeilen. Ende: eine Abfrage mit dem größten Anteil an der Datenbankzeit.

Schritt 7: Schnittstellen messen

Erheben Sie je Schnittstelle zwei Werte: die Dauer eines Laufs und den Rückstand. Notieren Sie die Dauer in Millisekunden und zählen Sie zu zwei festen Uhrzeiten, wie viele Nachrichten oder Sätze noch nicht verarbeitet sind und wie alt die älteste wartende Nachricht in Minuten ist. Steigt das Alter bei gleichbleibender Dauer eines Laufs, ist das ein Verdacht darauf, dass die Gegenstelle langsamer arbeitet als Ihre Anwendung sendet; dieselbe Wirkung haben eine stockende eigene Verarbeitung, eine Warteschlange und Wiederholungen. Der Verdacht gilt erst als bestätigt, wenn eine getrennte Messung von Wartezeit und Bearbeitungsdauer ihn stützt: die Wartezeit zeigt das Alter der wartenden Nachricht, die Bearbeitungsdauer eine Aufzeichnung der Gegenstelle. Läuft die Schnittstelle über HTTP, kann die Gegenstelle ihre eigene Dauer über den Kopf Server-Timing zurückmelden; damit trennen Sie Ihre Laufzeit von der der Gegenstelle. Zählen Sie Fehlversuche und Wiederholungen je Lauf, weil sie Last erzeugen. Messung: Alter der ältesten wartenden Nachricht in Minuten und Dauer eines Laufs in Millisekunden. Für das Zusammenspiel mehrerer Anbindungen hält der Beitrag Schnittstellenfehler überwachen die Wiederholungsregeln bereit. Ende: ein Rückstandswert je Schnittstelle zu zwei Uhrzeiten.

Schritt 8: Eine Größe ändern und dieselbe Messung wiederholen

Ändern Sie genau eine Größe und wiederholen Sie die Messung unter denselben Bedingungen: gleiche Uhrzeit, gleiches Gerät, gleicher Datensatz. Wird der Wert nicht besser, nehmen Sie die Änderung zurück. Halten Sie je Versuch Datum, Aktion, geänderte Größe, Messwert vorher und Messwert nachher fest. Änderungen an Einstellungen und Programmen planen Sie so, wie es die Update-Strategie fürs ERP für Testsystem und Freigabe beschreibt. Ende: eine belegte Verbesserung oder eine zurückgenommene Änderung.

Eine Beispielrechnung mit erfundenen Werten

Ein Handelsbetrieb öffnet die Maske Auftragsliste; sie erscheint nach 4,9 Sekunden, der Bericht Deckungsbeitrag läuft 9,2 Sekunden.

Messung	Auftragsliste	Bericht Deckungsbeitrag
responseStart (Millisekunden)	1.450	9.050
Span der Anwendung (Millisekunden)	1.200	8.900
Datenbankzeit der Abfrage (Millisekunden)	40	8.400
sichtbare Anzeige (Millisekunden)	4.900	9.200

Bei der Maske liegen von den 1.450 Millisekunden bis zum Beginn der Antwort 1.200 in der aufgezeichneten Dauer der Anwendung; die übrigen 250 Millisekunden verteilen sich auf den Weg der Anfrage, die Warteschlange vor der Anwendung und den Rest bis zum ersten Byte der Antwort, ohne dass diese zwei Messwerte sie trennen. Die 3.450 Millisekunden bis zur sichtbaren Liste (4.900 minus 1.450) sind eine Obergrenze für den Anteil des Arbeitsplatzes; darin stecken der Rest der Übertragung und das Laden weiterer Ressourcen. Beim Bericht stecken von 8.900 Millisekunden Serverzeit 8.400 in der Abfrage; dort ist der Ausführungsplan der Ansatzpunkt.

So prüfen Sie das Ergebnis

• Die betroffene Aktion ist mit Rolle, Gerät und Uhrzeit beschrieben und wiederholbar.
• Für jeden der fünf Zweige liegt ein Messwert mit Einheit und Zeitstempel vor.
• Die Systemzeiten der beteiligten Systeme sind synchron.
• Jeder Messwert ist mit dem Bezugswert desselben Falls verglichen.
• Der Zweig mit dem größten Anteil an der Gesamtdauer ist benannt.
• Ein Verdacht auf die Ursache ist durch eine zweite, unabhängige Messung gestützt und nicht aus einem einzelnen Messwert geschlossen.
• Die Zeit zwischen dem Beginn der Antwort und der sichtbaren Anzeige ist als Obergrenze für den Arbeitsplatz notiert, nicht als dessen reine Rechenzeit oder als Netzwerkzeit.
• Je Versuch wurde eine Größe geändert und erneut gemessen.

Wenn etwas nicht klappt

Symptom	Mögliche Ursache	Umgang
Der Bericht läuft lange, die Abfrage misst nur Millisekunden	Die Zeit steckt in der Übertragung oder im Aufbau der Ergebnismenge	die Ergebnismenge und die Zeit bis zur sichtbaren Anzeige messen
Das Echo zum Server ist unauffällig, der Druck am zweiten Standort bleibt langsam	Die Rundlaufzeit zeigt keine Wartezeit bei großen Datenmengen	Leerlauf und Last getrennt messen und die TCP-Effizienz erheben
Zwei Protokolle widersprechen sich	Die Systemzeiten laufen auseinander	die Systemzeit prüfen, bevor Sie Einträge gegenüberstellen
Nach jeder Änderung ist der Wert anders, aber nicht besser	Mehrere Größen wurden gleichzeitig geändert	je Versuch eine Größe ändern und denselben Fall erneut messen
Der Ausführungsplan sieht unauffällig aus, die Maske bleibt langsam	Gemessen wurde die Datenbank, nicht die Anwendung	den Span der Anwendung für dieselbe Aktion auswerten

Wann Sie Hilfe holen sollten

Holen Sie die IT-Betreuung oder den Hersteller dazu, wenn der Span der Anwendung die Zeit trägt und Ihre Rechte für Änderungen an der Anwendung nicht ausreichen. Für die Datenbank brauchen Sie jemanden, der Ausführungspläne liest, sobald eine Abfrage den größten Anteil hält; für den Netzwerkzweig die Stelle, die den Übertragungsweg betreibt. Nennt ein Vertrag eine Reaktionszeit, richten Sie den Schwellwert daran aus, wie es der Beitrag ERP-Supportvertrag prüfen beschreibt. Fällt die Arbeit während einer Störung länger aus, hält der Notfallplan für den ERP-Ausfall fest, was per Papier weiterläuft.