Wir alle wollen, dass unsere Automic Systeme so schnell laufen, wie nur möglich. Deshalb sollte man regelmäßig Performance-Messungen durchführen.

Wenn du die Leistung deines Automic Systems testen willst, stehen dir mehrere Möglichkeiten offen.

Eine davon kennst du wahrscheinlich: In der Administrations-Perspektive kannst du dir mit der Auslastungsgrafik die (wer hätte es gedacht?) Auslastung deines Systems ansehen.

Zwei andere Möglichkeiten stelle ich in diesem Artikel vor. Beide gehören zum Automic-Standard und bieten etwas mehr Informationen als die Auslastungsgrafik.

Der Performance Index

Als Erstes werfen wir einen Blick auf den Performance Index.

Auf der Automic-Website kannst du ein Tool zur Performance-Messung herunterladen.

Wie du das Tool installierst und verwendest, wird auf der Seite ganz gut beschrieben. Deshalb kommen wir gleich zum spannenden Teil: der Performance Messung

Das Tool führt Aktivierungen durch und misst den Durchsatz. Am Ende spuckt es dann einen einzelnen Wert aus, den sogenannten Automic Performance Index. Für sich genommen hat dieser Wert keine besondere Bedeutung, aber er dient als Vergleichswert.

Du kannst dein System immer wieder messen und die Performance zu unterschiedlichen Zeitpunkten miteinander vergleichen. Gibt es einen Trend? Wird dein System performanter oder nicht?

Du kannst den Automic Performance Index aber auch verwenden, unterschiedliche Systeme miteinander zu vergleichen.

Außerdem gibt es einige Referenzwerte von Automic, die von der Anzahl an WPs abhängen. Im besten Fall erreicht dein System den passenden Referenzwert. Oder übersteigt ihn sogar.

Auf der Downloadseite findest du auch eine grafische Übersicht über Referenzwerte sowie anonymisierte Werte anderer Kunden-Systeme.

Diagramm mit Referenzwerten für den Performance Index (Quelle: Automic Download Center).

An den blau markierten Automic-Referenzwerten kannst du einen Trend erkennen: Der Performance Index steigt fast linear mit er Anzahl an WPs. Zumindest bis ca. 50 WPs ist das laut dieser Grafik so.

Das bedeutet im Umkehrschluss, dass du die Systemperformance verbessern kannst, indem du einfach die Anzahl an WPs  erhöhst – mache das aber nur, wenn noch ausreichend CPU-Kapazitäten und Speicher auf deinen AE-Servern frei sind!

Durchschnittliche Transaktionszeiten

Im Sizing-Guide der Dokumentation findest du einen Bereich über „Transaction Times“.

Dort steht, dass Transaktionszeiten ein Indikator für die Performance des Gesamt-Systems sind.

Es gibt dort einen Beispiel-Screenshot wo eine „Avg. Time SR“ von „0,0159“ zu erkennen ist.

Oh, ein Durchschnittswert. Aber wie bekommt man den eigentlich?

Der Begleittext zu dieser Info ist wahrscheinlich einer der am wenigsten hilfreichen in der gesamten – und normalerweise doch wirklich sehr guten – Dokumentation. Dort steht, dass man die folgenden Schritte durchführen soll:

  1. Minimal Trace aufdrehen
  2. Tracing für 2 Minuten aktiviert lassen
  3. Trace-Files zusammensammeln
  4. Trace-Files Auswerten

Darunter erhält man dann noch die außerordentlich nützliche Information, dass der Wert nicht mehr als 0,05 betragen sollte. Und dass bei einem Wert über 0,2 so richtig Feuer am Dach ist.

Im Abschnitt „Troubleshooting“ stehen dann noch ein paar Hinweise, wo man ansetzen kann, um die Transaktions-Zeiten zu verbessern.

Alles klar! Oder?

Wahrscheinlich nicht. Denn selbst einige der erfahrensten Automic-Cracks da draußen kommen mit dieser minimalistischen Anweisung nicht zurecht. Wie genau soll man die Trace-Files auswerten? Und wie kommt man an die durchschnittliche Transaktions-Zeit?

Hier deshalb für euch meine etwas detailliertere (und hoffentlich verständlichere) Beschreibung, wie man die durchschnittliche Transaktions-Laufzeit des eigenen Systems ermittelt:

  1. Minimal Trace aufdrehen
    Dieser Punkt sollte selbsterklärend sein. Wenn du dich mit Tracing noch nicht gut auskennst, empfehle ich dir den Besuch einer Admin-Schulung oder alternativ ein Selbst-Studium mithilfe der Automic Dokumentation zum Thema Tracing.
  2.  Tracing für ca. 2 Minuten aktiviert lassen.
    Auch das sollte noch klar sein.
  3. Trace-Files zusammensammeln.
    Dieser Punkt hat zwei Teilschritte. Zunächst musst du die Traces von allen Server-Nodes sammeln und in einen Ordner irgendwo gemeinsam ablegen.
    Danach musst du die Traces noch mithilfe des Automic Dienstprogramms AE.LogMix zu einem Gesamt-Tracefile zusammenführen.
    Das Utility ist in der Doku erklärt. Der folgende Aufruf zum Beispiel fasst alle Zeilen aus den Tracefiles WP*.txt in die Datei Output.txt chronologisch zusammen:

    ucyblgmx -B -LWP*txt -FOutput.txt
  4. Trace-Files auswerten
    Dieser Punkt ist am wenigsten klar. Wie genau soll man das „auswerten“?

Automic hat beim Erstellen des Beispiel-Screenshots ein wenig geschummelt: Es gibt ein Automic-internes Tool, dass die Auswertung der Traces durchführt.

Dieses Tool heißt log.exe. Früher bekam man das Tool und eine Erklärung dazu beim Automic-Training „Admin Advanced“. Ob es dieses Training noch gibt oder das Tool nun Teil eines anderen Trainings ist, weiß ich leider nicht, da sich derzeit bei Automic (und insbesondere bei Automic Services) alles im Wandel befindet.

Du brauchst log.exe aber nicht, wenn du einfach nur aus dem Gesamt-Tracefile „Output.txt“ die durchschnittliche Zeit aller Server-Routinen willst (das ist diese „Avg. Time SR“, d. h. die „durchschnittliche Transaktions-Zeit“).

In den Minimal-Traces wird der Start und das Ende jedes Server-Routinen-Aufrufs mitgeloggt. Server-Routinen und Subroutinen haben eine Hierarchie und werden auch hierarchisch geloggt.

Zeilen zum Ende der Routine beginnen mit „EXIT“ und enthalten hinter „TIME:“ die Laufzeit der Routine.

Screenshot Auszug aus Output.txt.
Blau hervorgehoben: Eine JPEXEC_R Routine inklusive Subroutinen.
Rot hervorgehoben: Die Laufzeit der Routine in der dazugehörigen EXIT-Zeile.

Um die durchschnittlichen SR Zeiten zu messen, brauchen wir nur die oberste Ebene, die Subroutinen interessieren uns nicht.

Wir müssen also nur die Zeilen auswerten, die den String „- EXIT“ enthalten, und dann von diesen Zeilen den Durchschnitt der „TIME:“-Werte berechnen.

Das geht zum Beispiel mit folgendem Powershell-Codeschnippsel.

Select-String -CaseSensitive "- EXIT " .\Output.txt | Foreach-Object {
     # die spitzen Klammern in der regex legen Attribute an
     # das type-Attribut wird bei dem Beispiel aber nicht verwendet
     if ($_ -match "EXIT (?<type>[\w_]+) .*TIME: (?<time>[\d,]+)") {
         # ersetzt Komma durch Punkt, damit es als Dezimalzahl erkannt wird
         $matches.time -replace ",","."
     }
 } |  Measure-Object -Maximum -Minimum -Average

Zusätzlich zum Durchschnitt spuckt uns das auch noch den kleinsten und den größten Wert aus, sowie die Anzahl der gemessenen Server-Routinen. Vielen Dank für dieses Skript, Joel!

So könnte der Output des Skripts aussehen.

Ich habe 384 Server-Routinen in den Traces. Die kürzeste hat 0,0000 gedauert, die längste 0,191. Der Durchschnitt über alle Transaktionen war 0,0168 – Glück gehabt, das ist ein perfektes Ergebnis! 🙂

Damit wünsche ich dir auch viel Erfolg bei der Performance-Messung deines Systems!

Ich hoffe, das Ergebnis deiner Messung ist nach deinem Geschmack!