© Excellent backgrounds/Shutterstock.com
Teil 2: Störfall mittels Queueing-Network-Model untersuchen

Verdacht auf schlechte Performance


Was ist schlechte Performance? Letztendlich ist das dem Kunden egal. Der Kunde hat eine Störung in seinem Prozessablauf, wenn er von einem Performanceproblem spricht. Die Störung zeigt sich sicherlich auch an der Software, die der schlechten Performance verdächtigt wird. Ob sie die Ursache ist, ist eine andere Frage. Dies wollen wir klären und zeigen, wie man sich Schritt für Schritt der Ursache oder den Ursachen nähern kann.

Artikelserie

Teil 1: Mean Value Analysis

Teil 2: Störfall mittels Queueing-Network-Model untersuchen

Im folgenden Fall hatte der Kunde bei einer Anwendung Probleme mit dem Durchsatz. Es stauten sich im Laufe des Arbeitstags Aufträge, die an ein abgesetztes System gesendet werden sollten, das zentrale Aufgaben für mehrere Geschäftsbereiche erbringt. Die nächsten Tage kommen gewöhnlich jeweils noch einmal so viele Aufträge neu hinzu. Das ist ganz klar eine schwerwiegende Störung im Prozessablauf. Der Kunde hat das im fachlichen Monitoring seiner Prozesskette entdeckt. Wie sich das aber (ganz anders?) DV-technisch auf der Prozesskette darstellt, wollen wir uns genauer anschauen.

In dem dem Störfall zugrunde liegenden Szenario sendet eine Anwendung (Abb. 1) im Hintergrund immer einen Auftrag nach dem anderen an das Backend, das zuständig für die zentralen Aufgaben ist. Dieses verarbeitet den Auftrag und aktualisiert seine Datenbank. Ist der Auftrag erledigt, das heißt, hat der Consumer eine Antwort vom Backend erhalten, schaut er sofort in seiner Datenbank nach, bereitet die Daten auf und sendet einen neuen Auftrag los. Wie heute oft weit verbreitet, geschieht die Kommunikation nicht direkt zwischen Consumer und Provider, sondern über eine SOA-Infrastruktur. Das führt noch zu zusätzlicher Latenz und auch Komplexität, besonders bei der Untersuchung.

Der (Auftrags-)Strom Xconsumer ist ein klassisches Beispiel für einen Strom in einem geschlossenen Netzwerk (Closed Queueing Network). Allerdings fällt schon auf den ersten Blick auf, nicht ganz überraschend, dass der Consumer weniger als eine halbe CPU auf dem Backend verbrauchen sollte. Viele andere Prozesse im Backend dominieren also das Verhalten des Servers. In Abbildung 2 ist schon einmal die Last/Queue Q > 12 zu sehen. Näheres zu Queue Q findet sich im Kasten „Bemerkung zur Last, Queue-Length und Runqueue“. Schon diese Überlastung ist ein Indiz, dass der signifikante Performanceeinbruch (hier ein Durchsatzeinbruch) im Tagesverlauf durch die starke Serverüberlastung des Backend-Systems...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang