kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 12

APDEX – Der Application Performance Index

Der Application Performance Index (APDEX) wurde von einem Verbund
führender Firmen als verständliche Grundlage und als aussagekräftiger
Algorithmus im Umfeld der Anwendungs-Performancemessung im Jahre
2004 konzipiert.

Der Leitsatz des APDEX-Konsortiums ist: „Es ist immer nur das zu messen
was auch wirklich sinnvoll ist“. Die APDEX Methode konvertiert mehrere
Messwerte in eine einzige aussagekräftige Dezimalzahl zwischen 0 (kein
Benutzer zufrieden) und 1 (alle Benutzer zufrieden). Um dieses zu erreichen
veranstaltet man mehrere Messreihen mit reproduzierbaren repräsentativen
Use-Cases inklusiver einer maximal vertretbaren Antwortzeit, wie wir sie
gerade eben vorgestellt haben.

Blog #1.5

Wenn nun also die maximal akzeptable Antwortzeit Tmax=5 Sekunden
festgelegt wurde, bedeutet dies das sich die „tolerierende“ Zeitspanne bis
zum Punkt F = 4 x Tmax, also 20 Sekunden erstreckt. Alle Antwortzeiten >20
Sekunden werden somit als für den Endbenutzer „frustrierend“ angesehen.

Die verschiedenen Akzeptanz-Level im einzelnen:

  • Satisfied – der Benutzer bleibt auf die Aufgabe fokussiert. Performance spielt keine Rolle in der Benutzererzufriedenheit, das gesetzte Zeitlimit ist konsistent.
  • Tolerating – der Benutzer ist teilweise akgelenkt. Performance spielt eine Rolle in der Benutzererzufriedenheit, der Benutzer empfindet die Wartezeit zu lang.
  • Frustrated – der Benutzer bricht teilweise die Aufgabe ab. Performance ist inakzeptabel, der Benutzer wird höchstwahrscheinlich die Arbeit einstellen.

Nehmen wir nun an wir haben das vormals festgelegte Szenario insgesamt
zehn Mal durchgespielt und erhalten die nachstehen Meßwerte, ergäbe dies
anhand der Formel für einen Schritt daraus folgende Zuordnung:

  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=8 Sekunden) > SATISFIED
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=9 Sekunden) > TOLERATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=15 Sekunden) > TOLERATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=5 Sekunden) > SATISFIED
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=40 Sekunden) > FRUSTRATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=55 Sekunden) > FRUSTRATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=20 Sekunden) > TOLERATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=12 Sekunden) > TOLERATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=45 Sekunden) > FRUSTRATING
  • Sprung in das Portlet MyData, Ansicht customisieren > klick auf # … (T=8 Sekunden) > SATISFIED

Mit Hilfe der folgenden Formel können wir nun den Dezimalen APDEXT
errechnen:

Blog #1.6

Blog #1.7Man kann nun dieses Ergebnis in ein globales Ergebnis und eine Endaussage treffen. Ein APDEXT von 0,50T entspricht einer sehr schlechten Performance im tiefroten Bereich „Poor“ an der Grenze zu „Unacceptable“.

Die Erfahrung hat gezeigt, dass es durchaus ratsam ist bereits ab einem Wert von 0,80T korrektive Aktionen oder weitergehende Tests auf dem Portalbackend zu planen, da man technische Ursachen und Probleme im Echtbetrieb später nicht ausschließen kann.

 

Weitere Tools und Performance -­ Tuningmöglichkeiten von Portalen

Neben den technischen Möglichkeiten zur Leistungsverbesserung, wie dem Einbau
zusätzlicher CPU- und RAM-Kapazität, des Tunings der softwareseitigen
Zuweisung von reserviertem Speicherplatz wie im Falle von JAVA-Startparametern
oder speziellen SSL-Accelerator-Netzwerkkarten für HTTPS-Verschlüsselung gibt
es darüberhinaus noch eine fast unüberschaubare Anzahl von weiteren
Optimierungsmöglichkeiten für eine Verbesserung der Portalperformance.

Zum einen liegen oftmals viele Probleme mit Latenzen in firmeninternen
Netzwerken in der richtigen Konfiguration des Netzwerkes. Schon ein paar
hundertstel verlorene Millisekunden pro Objekt bei der Anfrage zum DNS-Server
zur Auflösung der IP-Adresse können sich bei einer komplexen Portalseite mit
vielen Objekten zu Sekunden aufsummieren. Falsch konfigurierte Internet-Proxy-
Server, die erst einmal jede interne Anfrage erfolglos in das World-Wide-Web leiten,
nur weil eine Subdomain falsch in der „No-Proxy“ Konfigurationsdatei für eine
einzelne Portal-Maschine eingetragen ist können sporadisch katastrophale
Antwortzeiten für bestimmte Services verursachen. Deshalb ist Code-Optimierung
wichtig.

Meistens sind die Ursache für hohe Antwortzeiten ein halbherzig per Skript statt
durch Hardware konfiguriertes Load-Balancing, welches basierend auf geraden
oder ungeraden eingehenden IP-Adressen in heterogenen Netzwerken mit vielen
Nutzern (hinter Reverse-Proxies oder Gateways) die Requests umverteilen soll.

Dies ist nur eine kleine Auswahl an Problemen auf die wir im Laufe der Zeit im
Zusammenhang mit der Performance von Portalen gestoßen sind und die gewiss
kein Einzelfall sind. Diese Art von fehlerhaften Konfigurationen lassen sich
allerdings nur zuverlässig im Rahmen von extensiven Performance-Testkampagnen
entdecken.

Neben diesen technischen Ursachen auf Seiten der Konfiguration der Komponenten
gibt es auch auf Seiten der Portale selbst ebenfalls einige Ansatzpunkte
zum wirkungsvollen Tuning.

Portalseiten sind von der Struktur her meistens recht kompliziert aufgebaut, dies
ist der dynamischen Generierung der Seiten zur Laufzeit in Abhängigkeit zur
Benutzeridentität in der Portalengine geschuldet.

Viele einzelne Komponenten fügen sich zu einem personalisierbaren Gesamtbild
zusammen und genau hier bestehen weitere Ansätze der Optimierung des
generierten HTML-Codes. Schaut man sich die generierte Portalseite im Browser
an, erkennt man in den meisten Fällen duplizierte Objekte.

Mal sind es redundante CSS-Einträge, doppelte JavaScripte oder ganz einfach
überflüssige Blankspaces oder gar Kommentare im HTML-Code, die unnützen und
vor allem vermeidbaren Ballast und somit Bytes/Übertragungszeit – also
letztendlich kostbare Wartezeit für den Benutzer des Portals bedeuten.

Fortsetzung in Teil 13:

Im nächsten Teil geht es um Client Tools für die Analyse, Anwendungen zum Durchführen von Tests und um einen starken Preojektpartner.

Lesen Sie hier ab dem 13.11 den Teil 13

Share