Der folgende Blogbeitrag beschreibt, wie mit der dargestellten Anwendung schnell und flexibel die Ausführungszeiten von Berichten mit Hilfe von DeltaMaster erfasst und analysiert werden können. Im Fokus steht hier, die oft durch Anwender als „gefühlte Verschlechterung der Performance“ beschriebene subjektive Einschätzung anhand von manuellen Messungen mit Daten zu unterfüttern. Es werden allgemeine Einflussfaktoren, das Messverfahren und die Ergebnisdarstellung beschrieben.

Zum Ende wird ein Ausblick über den weiteren Ausbau der Anwendung und neue Anforderungen hinsichtlich der Automatisierung dieses manuellen Ansatzes dargestellt.

Performance, gefühlt oder tatsächlich?

Wer kennt das Thema in seinen Projekten nicht: Nach erfolgreichem Projektabschluss wird die Anwendung in den operativen Betrieb übergeben, verschiedene Benutzergruppen beginnen mit ihrer täglichen Arbeit, in Planungsprojekten finden erste Dateneingaben statt und nach einer mehr oder weniger kurzen Zeit kommen die ersten Anmerkungen zum Thema Antwortzeiten. Typische Aussagen der Anwender sind dann schnell: „Im alten System ging das aber schneller.“ Oder: „Mit der vorherigen Version musste man nicht so lange auf die Ergebnisse warten.“ Willkommen in der Welt der Performance von Softwareanwendungen. Das Thema ist vielschichtig, denn es gibt diverse Einflussfaktoren:

1. Netzwerk
   • Wie wird auf die Anwendung zugegriffen? Per Webclient oder direkt vom Clientrechner mit Hilfe des Rich-Clients DeltaMaster?
   • Wie gut (oder schlecht) ist die verwendete Netzwerkverbindung? Gibt es unterschiedliche Ausführungszeiten zwischen den verwendeten Verbindungen?
   • Wie findet die Authentifizierung der Benutzer statt? Liegen hier bereits Verzögerungen vor?
2. Serversysteme
   • Wie performant sind die beteiligten Serversysteme?
   • Wenn die Datenbanksysteme hohe Antwortzeiten liefern, welcher Bereich genau (MDX und/oder SQL) des Microsoft SQL-Servers ist betroffen?
3. DeltaMaster
   • Sind alle Berichte/Eingaben in DeltaMaster von langen Antwortzeiten betroffen oder nur einzelne Abfragen?
   • Melden alle Benutzer derartige Auffälligkeiten oder nur bestimmte Benutzer/-gruppe(n)?

Neben den technischen Einflussfaktoren kommt ein weiterer Aspekt hinzu: Wie kann die Performance überhaupt gemessen werden? Bereits bestehende Informationen wie das MDX.log oder die Logbook-Anwendung von DeltaMaster Repository stellen nur Informationen in Bezug auf die Serverabfragen bereit, nicht aber die operative Erfahrung unserer Anwender.

Eine Frage des Blickwinkels

Genau an dieser Stelle kann es schnell zu Missverständnissen bzw. unterschiedlichen Wahrnehmungen kommen. Aus Entwicklersicht kann eine Wartezeit von 10 Sekunden für die Anzeige eines Berichts akzeptabel sein (große Anzahl an Zeilen, komplexe Berechnung von Kennzahlen, die Datenübertragung o. ä.). Anwender haben aber genau dieses Verständnis nicht zwingend oder interessiert es schlichtweg nicht. Der gesamte Nutzen einer Anwendung (und damit auch der nachhaltige Erfolg des Projekts) hängt aber von der Akzeptanz der Anwender ab, daher dürfen wir derartige Rückmeldungen nicht einfach auf technische Gegebenheiten (ohne mindestens grobe Analyse) abschieben.
Dieser Blogbeitrag beschreibt eine kleine Anwendung zur Erhebung und Dokumentation von Antwortzeiten, um die oft als „gefühlt“ bezeichneten Ergebnisse festzuhalten und strukturiert auswerten zu können.

Das Messverfahren

Da das Thema wie unter Punkt 1 beschrieben die verschiedensten Aspekte beinhaltet und dadurch auch viele Optimierungsansätze besitzt, sollten wir durch die einfache Messung der Antwortzeiten unserer Berichte dem Gefühl der Anwender die tatsächlich messbaren Auffälligkeiten gegenüberstellen. Diese Ergebnisse lassen dann eine Priorisierung nach dem Prinzip Aufwand/Nutzen zu, wodurch sich weitere notwendige Analysen ableiten lassen. Erst wenn die Prioritäten klar sind, können wir die notwendigen internen oder externen Spezialisten hinzuziehen.
Dieser Ansatz verfolgt eine manuelle Endpunkt-zu-Endpunkt Messung. Das bedeutet, wir messen per Stoppuhr verschiedene Phasen bei der Arbeit eines Anwenders mit DeltaMaster.

Datenmodell

In diesem Beispiel (Live so im Projekt geschehen) haben wir mit dem Kunden folgende Prozessschritte als Messpunkte gemeinsam festgelegt:

Abbildung 1: Dimension ProcessStep

zu 1 = Belastung des Clientrechners zum Start von DeltaMaster
zu 2 = Laden der Anwendung aus Repository und Berechnung des Startberichts
zu 3 – 7 = nach Auswertung der Anwendung „Logbook“ die Top 5 Berichte nach Häufigkeit des Aufrufs
Da im Lebenszyklus der DeltaMaster-Anwendungen unterschiedliche Versionen eingesetzt und diese oft auf unterschiedlichen Infrastrukturkomponenten aufgesetzt werden, wird dieser Sachverhalt durch das Merkmal „DMVersion“ in den Messungen berücksichtigt.

Abbildung 2: Dimension DMVersion

Dies gilt auch für die unterschiedlichen Zielsysteme (hier: Intranet vs. Getrennte Netzwerkzonen (B2X)).

Abbildung 3: Dimension Landscape

Zu guter Letzt verwenden wir zusätzlich noch das Merkmal „Cycle“, um die Ergebnisse unterschiedlicher Messzyklen festzuhalten. Da wir aktuell nur manuell die Zeiten stoppen können und vor dem Hintergrund, dass eine punktuelle Messung nicht die Serveraktivität zum Zeitpunkt der Messung berücksichtigt, können diese Einflussfaktoren zumindest in der Analyse als Durchschnittswert betrachtet werden und bilden somit ein belastbareres Messergebnis.
Die Kennzahl „Duration“ ist als Fließkommawert in Sekunden definiert.
Die Datenerfassungsmaske sieht anschließend wie folgt aus:

Abbildung 4: Eingabebericht Measurements

Technisch ist die Eingabe der Messwerte als „normale“ Hybrideingabe umgesetzt. Aufgrund der gerin-gen Anzahl von Benutzern und der geringen Anzahl von Eingabewerten ist das Delta-Hybrid Verfahren nicht notwendig. Natürlich können die Merkmalsinhalte einfach in den zugrundeliegenden T_S_*-Tabellen für den jeweiligen Projektbedarf schnell angepasst werden.
Hinweis: Die aktuelle Version dieser kleinen Anwendung ist zu 100 % modelerfähig (DMM 213 Patch 2), d. h. auch das notwendige XMLA-Skript zum Aktivieren der ROLAP-Partition ist in den Metadaten hinterlegt.
Der für die Durchschnittsberechnung notwendige Datensatzzähler wird automatisch im Hintergrund durch die SQL-Prozedur „P_WriteBackSQL_FACT_01_Measurements_PostProcess“ gesetzt.

Analyse der Ergebnisse

Die mitgelieferte Anwendung DeltaMaster Performance Analysis liefert bereits 2 erste Analyseberichte zu den gemessenen Ausführungszeiten:

Abbildung 5: Bericht zum Vergleich unterschiedlicher Systemumgebungen

Dieser Small-Multiple-Bericht zeigt die durchschnittliche Ausführungszeit je definiertem Prozessschritt pro Zielsystemlandschaft. Hier ist klar erkennbar, dass die Umgebung „B2X“ um ein vielfaches langsamer in allen Bereichen (ausgenommen dem reinen Start von DeltaMaster) reagiert. Die Ursache liegt vermutlich in der Verwendung der Authentifizierungsmethode begründet. Die ermittelten Werte stützen also das Gefühl der Anwender und bedeuten gleichzeitig, dass weitere Detailanalysen für die Umgebung „B2X“ notwendig sind.
Dennoch klagen die Anwender auch für das System „G03“ teilweise über sehr lange Ausführungszeiten.

Abbildung 6: Bericht zum Vergleich der Ausführungsdauer versionsunabhängig

Der Bericht zeigt, dass es einen messbaren (und nicht unerheblichen) Unterschied zwischen Delta-Master Versionen gibt.
44,1 Sekunden für den Start der Applikation mit Version 5.6.5 MP 6 stehen 72,7 Sekunden im Mittel für den gleichen Vorgang mit DeltaMaster 6.1.5 gegenüber. Betrachtet man anschließend aber die Zeiten für einzelne Berichte, so wird deutlich, dass lediglich der Start (Ursachen noch nicht identifiziert) inklusive Laden des Startberichts verlangsamt ist. Das Gefühl der Anwender können wir also nur teilweise bestätigen (messen).

Als weiterer Punkt wird die Behauptung betrachtet, CITRIX als Applikationsplattform für DeltaMaster ist nicht praktikabel. Da wir auch diese Zeiten gemessen haben, ist ein Vergleich zu diesem Thema ebenfalls in Sekunden erstellt:

Abbildung 7: Vergleich Rich-Client und CITRIX

Die aktuelle Version von DeltaMaster 6 als Rich-Client startet deutlich schneller als DeltaMaster in Form einer freigegebene Applikation über einen CITRIX(-Farm)-Server. Die Berichtsabfragen sind vergleichbar schnell, aber die reine Startzeit des Clients ist deutlich langsamer und addiert sich noch zusätzlich um den Start des Citrix-Portals. Es empfiehlt sich also, die entsprechenden Systembetreuer zu kontaktieren und auf Optimierungspotentiale untersuchen zu lassen. In diesen Messungen ist übrigens nicht die Zeit für den Start des CITRIX-Portals einbezogen.

Ausblick

Die hier dargestellten Messungen sollten noch an unterschiedlichen Tagen wiederholt werden, um a) auch Aussagen im historischen Verlauf („dieser Bericht war sonst immer schnell?“) analysieren zu können und b) genauere Mittelwerte für die Ausführungsdauern zu erhalten. Je mehr Messungen enthalten sind, desto genauer sind die Ergebnisse und damit die Rückschlüsse hinsichtlich des weiteren Vorgehens.
Das Datenmodell werden wir in einer der kommenden Versionen in der Dimension „ProcessStep“ mit einer aggregierten Ebene versehen, um die Schritte thematisch klarer für die Anwender zu gruppieren.
Sollten in einer der kommenden Versionen von DeltaMaster die im Folgenden Punkt 5 definierten Wünsche umgesetzt werden, wird es dazu natürlich auch einen fertigen ETL- oder CustomApp-Prozess geben.

Wünsche

Wir benötigen mehr LogInformationen in der Repository Datenbank! Oder in Form von strukturier-ten Dateien (z.B. XML). Die manuelle Messung ist, auch wenn hier eine Anwendung zur Erfassung und Analyse zur Verfügung steht, weder zeitgemäß noch dauerhaft im Projekteinsatz wiederholbar.
Als weiteren notwendigen Detailierungsgrad der Log-Informationen sollten folgende Themen vom System erfasst werden:
Wie lange dauert der Applikationsstart

1. nach Datenbank-Abfrage
   • Repository-Abfragen für die Applikation
   • MDX-Abfrage (aktuell kann das MDX.log nicht automatisiert ausgewertet werden)
   • Ggf. SQL-Abfragen
2. Authentifizierung des Benutzers (Näherungsweise Differenz Zeitstempel zwischen Startklick Anwendung und erster Abfrage der OLAP-Datenbank)
3. Datenübertragung zwischen Client und Server
4. Aufbereitung (Rendering) für den Betrachter in DeltaMaster

Fazit

Sollten Sie in Ihrem Projekt auch mit der „gefühlten Langsamkeit“ der Anwendung nach einem Versionswechsel konfrontiert werden, empfehlen wir unbedingt die Dokumentation der Ergebnisse (gerne mit Hilfe dieser kleinen Anwendung). Nur so bekommt man neben dem Gefühl auch belastbare Zeiten, mit denen man weitere Priorisierungen von notwendigen Detailuntersuchungen steuern und verteilen kann.
Das Thema Performance kann oft nicht mit dem gern zitierten Schalter „fast = true“ abgehakt wer-den, je größer und komplexer die Systemumgebungen unserer Kunden, desto strukturierter sollte das Vorgehen sein.
Alle notwendigen Sicherungsdateien und die DeltaMaster Analysesitzung werden gerne jederzeit auf Nachfrage bereitgestellt.