End2End-Browser

Mit End2End-HTTP prüfe ich schon umfangreich die Erreichbarkeit und Latenzzeit zum Webserver. Es ist aber keine Auswertung echten Anwenderzugriffe. Browser-Plugins können aber sehr gut auch Kennzahlen im Browser ermitteln.

Real statt Test

Auch wenn ich mit End2End-HTTP schon die nackte Verbindung zum WebServer prüfe und zudem Kennzahlen des SharePoint-Servers (End2End-SharePoint) mit erfasse so ist es immer nur ein Request pro Zeit auf eine bestimmte URL. Anwender arbeiten natürlich mit einem Browser, der zum Aufbau einer Seite mehrere URLs einsammelt und weitere Skripte o.ä. ausführt und Seiten rendert.

Aktiv ist dabei immer der Benutzer und mich würde schon interessieren, wie flüssig der Anwender arbeiten kann. Das kann meiner Einschätzung nach nur auf dem Client erfasst werden, da der Inhalt der WebServer nicht immer durch eigene Skripte ergänzt werden kann.

Es beginnt ja immer mit dem ersten Aufruf der URL und der abschließenden Meldung des Browser "Rendering done". Zudem lädt der Browser weitere Informationen während dem Zeitenaufbau nach. Insofern frage ich mir, wie diese Daten sinnvoll erfasst werden können. Relevant sehe ich hier

  • Performance für das Laden und Rendern der Seite
    Das müsste der Browser erfassen können, denn der Browser bekommt die Benutzer-Aktion (Mausklick) mit und meldet letztlich "Renderer done"
  • Individuelle Performance der Quellen
    Wenn der Browser auch jeden einzelnen Request und dessen Latenzzeit und Größe erfassen kann, dann könnte man damit auch die Gegenstellen hinsichtlich Performance weiter messen.

Dass dies technisch möglich ist, zeigen ja die F12-Developer Tools und auch das Page Diagnostics for SharePoint Tool (Siehe End2End-SharePoint). Beide Tools sind aber für eine sinnvolle datensparsame Erfassung aber nicht geeignet.

Also habe ich auf die Suche gemacht und wurde auch fündig:

The Navigation Timing API provides data that can be used to measure the performance of a web site. Unlike JavaScript-based libraries that have historically been used to collect similar information, the Navigation Timing API can be much more accurate and reliable.
Quelle: https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API

Planung

Der Anwender "surft" quasi durch seine Anwendungen und das ist bei weitem nicht nur das Internet sondern auch viele interne Services nutzen mittlerweile HTTP. Damit man dennoch nicht alles erfassen muss, würde ich mit auf die "Hauptseiten" einer Domain-Whitelist beschränken, die für den Mitarbeiter relevant sind. Also immer, wenn der Anwender eine URL aus dieser Liste aufruft, dann erfasst die Extension die Gesamtladezeit der Hauptseite und Latenzzeit/Datenmenge der für die Seite nachgeladenen Zeiten nach Domain. Zumindest in der ersten Version erhoffe ich mir, dass diese Datenmenge für eine Performance-Messung ausreicht. Am Ende habe ich dann

  • Eine Liste der aufgerufenen URLs bestehen aus Domain, URL (hash) mit Zeitpunkt, Datenmenge, Ladezeit, MB gesamt
    Damit sollte man "Beschwerden" des Anwenders anhand der Uhrzeit schon halbwegs gut nachvollziehen können und auch erkennen, ob es nur bestimmte Webseiten betrifft
  • Eine Liste der Domains mit Min/Max/Avg Ladezeit und Min/Max/Avg Durchsatz und MB Gesamt über jede 10 Minuten
    Fast alle Webseiten laden irgendetwas woanders nach, z.B. CSS, Bilder, Skripte etc. Wenn man nur die Werte pro Domain zusammenfasst, könnte diese die weitere Analyse unterstützen ohne zu viele Daten zu sammeln

Damit erhalte ich natürlich kein 100% genaues Tracking einzelner Requests, was aber auch hinsichtlich Datenschutz kritisch zu sehen wäre. Es ist auch nicht lückenlos, da der Anwender ja aktiv etwas tun muss. Mit den Zahlen lassen sich dann aber generische End2End-HTTP-Requests erstellen.

 

Umsetzung

Das ist dann noch die Baustelle. Ich hatte bislang weder Zeit noch Ressourcen ein Browser PlugIn zu bauen und die Daten in das End2End-Monitoring zu addieren.

 

Weitere Links