Sollte die Performance von raum]für[raum einmal nicht den Erwartungen entsprechen, ist es nötig, nach der Ursache zu suchen. Dabei kann das Performance-Monitoring weiterhelfen.
Ein Anwendungsfall mit realen Erfahrungswerten kann zusätzlich eine Untermauerung bei potentiellen Skalierungsfragen der Infrastruktur darstellen.

Das besondere am Performance-Monitoring ist, dass der gesamte Lebenszyklus einer Anfrage (Request) bis zur Verarbeitung der Antwort (Response) aus Sicht des Benutzers erfasst und gemessen wird. Somit erhält man nicht nur reine Performance-Informationen des Webservers, sondern kann diese auch in Relation zu dem verwendeten Client und seiner Netzwerkanbindung setzen.

Sammeln von Daten: Aufzeichnen der eingehenden Requests an raum]für[raum

Das Performance-Monitoring kann in der System-Initialisierung aktiviert werden. Der Faktor bestimmt dabei, wie viele Requests für eine Auswertung aufgezeichnet werden. Da das Aufzeichnen der Requests selbst sowohl Rechenzeit als auch Datenbank-Speicher benötigt, empfiehlt es sich in stark genutzten Produktivsystemen, das Monitoring nur zeitweise oder mit einem Faktor > 1 einzuschalten.

Auswerten der aufgezeichneten Daten

Der System-Menüpunkt „Performance-Monitoring" stellt die aufgezeichneten Daten mit diversen Filter- und Aggregierungsmöglichkeiten tabellarisch dar:

Auswertungstypen

Es stehen drei Auswertungstypen zur Verfügung:

  • Web (programMANAGER, Applikation)
    Hier werden bis auf wenige Ausnahmen alle Requests aufgezeichnet, die über einen Webbrowser generiert werden.
  • SOAP API (Mobile App, ADD.IN)
    Hier werden alle Requests an die SOAP API aufgezeichnet.
  • iCal-Abonnements
    Hier werden alle Requests der iCal-Abonnements aufgezeichnet.

Bei aktiviertem Performance-Monitoring werden Daten für alle Auswertungstypen erfasst. Da diese aber je nach Typ auf unterschiedlichen Technologien beruhen, können sie nicht untereinander gemischt und miteinander verglichen werden.

Aggregierung

Die aufgezeichneten Requests werden als Tabelle aggregiert und nach wählbaren Kriterien dargestellt. Damit lassen sich Muster erkennen, die anschließend genauer untersucht werden können.

Zur Auswahl stehen folgende Aggregat-Kriterien:

Kriterium

Geeignete Anwendungsfälle (Beispiele)

Jahr, Monat

Langzeit-Vergleiche

Tag

Auswirkungen einer Veränderung (z.B. Installation eines Updates, Hardware-Skalierung, Rollout auf neue Nutzergruppen)

Stunde (im Screenshot ausgewählt)

Lastspitzen im Tagesverlauf

Administrator / Benutzer

Eingrenzung von Performance-Problemen auf Benutzer

Pfad (Auswertungstyp „Web": Angeforderte URL / Auswertungstyp „SOAP API": SOAP-Methode)

Eingrenzung und Vergleich von Programmstellen

User-Agent

Client-spezifische Unterschiede

Als Aggregatfunktionen stehen zur Verfügung:

  • AVG: Durchschnittliche Werte pro gewähltem Kriterium
  • MIN: Minimum-Werte pro gewähltem Kriterium
  • MAX: Maximum-Werte pro gewähltem Kriterium

Filtermöglichkeiten

Die auszuwertenden Requests können neben der zeitlichen Eingrenzung auch nach Pfad, Session-ID, Benutzer-ID und ID des Administrators eingegrenzt werden. Damit lassen sich nach dem Top-Down-Prinzip in Kombination mit den Aggregierungs-Kriterien die möglichen Flaschenhälse effektiv bestimmen. Dabei kann bei den Eingabefeldern auch der Wildcard-Platzhalter (%) verwendet werden.

Erläuterung der Spalten

In der ersten Spalte wird das im darüberstehenden Drop-down gewählte Aggregierungs-Kriterium inkl. der darin enthaltenen Anzahl der Requests (in eckigen Klammern) dargestellt. Die restlichen Spalten werden in vier Gruppen aufgeteilt (blau hinterlegt, mit Angabe des prozentualen Anteils des Zeitverbrauchs in eckigen Klammern):

Daten aus dem Bereich Netzwerk (inkl. „Zeit Send" und „Zeit Receive" aus dem Bereich Backend) und Frontend können aus technischen Gründen nicht in den Auswertungstypen „SOAP API" und  „iCal-Abonnements" erfasst werden und stehen dort nicht zur Verfügung.

Netzwerk

Im Bereich Netzwerk werden folgende Informationen erfasst:

  • Anzahl Redirects
    Wie häufig musste bei der Anforderung einer URL Weiterleitungen (HTTP-Status-Codes 3xx) gefolgt werden? Der häufigste Grund von Weiterleitungen sind z.B. fehlende Berechtigungen (Weiterleitung auf Login-Seite) oder Weiterleitungen nach einem Speichern von Daten.
  • Zeit Redirects
    Wie lange musste auf die Weiterleitungen gewartet werden? Sollte z.B. das Speichern von Daten recht lange dauern und danach eine Weiterleitung auf z.B. die Übersichtsseite erfolgen, kann der Zeitaufwand des Speicherns an dieser Stelle abgeleitet werden.
  • Zeit DNS
    Wie lange hat die DNS-Auflösung des Hosts gedauert?
  • Zeit Connect
    Wie lange hat der Verbindungsaufbau zum Host gedauert?

Backend

Im Bereich Backend werden folgende Informationen erfasst:

  • Zeit Send
    Wie lange hat es vom abgeschlossenen Connect bis zur vollständigen Übertragung der Request-Daten an den Server gedauert?
  • Zeit PHP
    Wie lange hat die Verarbeitung des Requests auf PHP-Seite gedauert? Darin enthalten ist auch die Kommunikation mit Drittsystemen (z.B. LDAP-Abfragen), aber keine Datenbank-Zeit, welche separat erfasst wird.
  • Memory (MB) PHP
    Wie hoch war die maximale Speichernutzung (Peak-Memory) von PHP?
  • Anzahl DB-Queries
    Wie viele Abfragen wurden an die Datenbank gestellt?
  • Zeit DB-Queries
    Wie lange haben die Abfragen an die Datenbank gedauert?
  • Zeit Receive
    Wie lange hat es gedauert, bis die Antwort zurück zu dem Client gesendet wurde.

Sowohl „Zeit Send" als auch „Zeit Receive" könnten auch dem Bereich Netzwerk zugeordnet werden.

Frontend

Dieser Bereich zeigt, wie lange der Client benötigt, um die enthaltene Antwort (Response) zu verarbeiten und darzustellen:

  • Zeit DOM
    Wie lange braucht der Browser, um das interne Document-Object-Model aufzubauen, also das enthaltene HTML-Dokument zu verstehen?
  • Zeit Render
    Wie lange braucht der Browser, um das interpretierte DOM zu zeichnen, also auf dem Bildschirm darzustellen? Dazu gehört auch das Nachladen von weiteren Ressourcen wie Bildern und Stylesheets.

Gesamt

  • KB Output
    Übertragene Datenmenge an den Client in KB, ohne Berücksichtigung einer evtl. webserverseitigen Komprimierung, welche immer empfohlen wird.
  • Zeit Gesamt
    Wie lange hat es vom Start der Anfrage bis zur vollständigen Darstellung der Antwort für den Benutzer gedauert?

Darstellung der Datenwerte

Die Werte sind das Ergebnis der oben gewählten Aggregatfunktion (AVG, MIN oder MAX) und lassen sich mit einem Klick auf den entsprechenden Spaltennamen auf- oder absteigend sortieren. Alle Zeiten sind in Millisekunden angegeben.

Um das Verhältnis der Werte einer Spalte visuell schnell erfassen zu können, werden diese mit einem grauen Balken hinterlegt. Dabei entspricht eine Balkenlänge, die über die gesamte Spaltenbreite reicht, 100% des größten Wertes dieser Spalte.

Löschen von nicht mehr benötigten Daten

Da die aufgezeichnete Datenmenge schnell sehr groß werden kann, können die jeweils nach den gewählten Filtern angezeigten Daten über den entsprechenden Button gelöscht werden, wenn sie nicht mehr benötigt werden.
Grundsätzlich empfiehlt sich ein Löschen der Daten, sobald die Ursache gefunden sowie behoben wurde und die eingetretene Verbesserung über das Performance-Monitoring verifiziert wurde.