End2End-SharePoint

Diese Seite beschreibt ein paar Besonderheiten bei der Überwachung und Reaktionsmessung mit SharePoint Servern, die ich bei Network Assessments zu Office 365 verwende. Ich habe dazu auf End2End-HTTP schon länger ein Skript bereit gestellt, mit dem ich per synthetischen HTTP-Anfragen die Reaktionszeit und Laufzeit über das Netzwerk und Proxy-Servern ermitteln.

Die ist eine in end2end-http enthaltene Erweiterung die mit SharePoint als Gegenstelle erweiterte Daten ermittelt. Es ist keine Lösung, um die Funktion von Sharepoint oder Performance aktiv zu messen oder Zugriffe zu simulieren.

Server-Performance

Die Herausforderung bei einer Messung mit HTTPS gegen einen Webserver ist immer die Frage, wie viel Zeit der Request auf dem Webserver benötigt. Anders als bei einem ICMP-Ping, der in der Regel sehr schnell beantwortet wird, kann ein Webserver schon etwas Zeit benötigen. Das gilt selbst dann, wenn die Datei eigentlich statisch ist. Der Webserver muss dennoch den HTTP-Request verarbeiten, die Information beschaffen und einen Reply formulieren.

Auch ein Proxy-Server dazwischen addiert ein paar Millisekunden und selbst wenn die Antwort dann beim Client ankommt, kostet das Parsing auf dem Client ebenfalls Zeit. Am meisten stört mich aber, dass Webserver bei dynamischen Seiten oft etwas länger brauchen und da ist es wünschenswert diese Informationen zu erhalten. Im IISLOG eines Windows-Server können Sie problemlos auch die Zeit protokollieren lassen, der der Webserver an der Aufgabe geknabbert hat. Allerdings haben Sie bei einer Cloud-Lösung auf diese Protokolle keinen Zugriff.

X-SharePointHealthScore

Umso mehr habe ich mich gefreut, als ich eher zufällig beim Tracen mit Fiddler oder auch den Debug-Optionen des Browser im HTTP-Header einer Antwort interessant Felder gefunden habe:

Bei einigen URLs addiert ein Sharepoint Server zusätzliche Felder in die Antwort, die ein normaler Client nie auswertet. Insofern sendet SharePoint Zusatzinformationen, die man schon gezielt abfragen muss. Die Bedeutung der Felder findet sich nach einiger Recherche:

Parameter

Beschreibung

SPIisLatency

Zeit in Millisekunden, die zwischen dem Empfang durch den IIS und vor der Verarbeitung durch die Web Application vergangen ist. In der Regel ist der Wert sehr klein <2ms, da beide Dienste auf dem gleichen Server laufen. Höhere Werte sind ein Zeichen, dass kein Worker im Pool zur Verfügung stand oder erst gestartet werden musste. Es kann passieren aber sollte nur kurz der Fall sein

SPRequestDuration

Zeit in Millisekunden, die der Worker mit der Verarbeitung verbringt. je nach Komplexität und Größe kann die Abfrage auch mehrere hundert Millisekunden dauern. Kürzer ist natürlich besser und letztlich sind es Mittelwerte und Maximalwerte, die zu betrachten sind. Hohe Werte in diesem Feld spiegeln sich auch in "x-sharepointhealthscore" wieder.

SPRequestGuid

Eine eindeutige GUID für den Request, mit der Sie bei einer Fehlersuche oder tieferen Analyse die Verarbeitung analysieren können. Mit der Request-ID kann auch ein Microsoft Support einfacher die Situation analysieren.

X-SharePointHealthScore

Dieser Wert gibt die Last des Servers zwischen 0 und 10 wieder. Niedrigere Werte sind besser. Wenn die Werte dauerhaft über 5 sind, dann sollten Sie die Performance des SharePoint Servers untersuchen lassen. Soweit ich gesehen habe, repräsentiert die Nummer keinen globalen Performancewert des Servers sondern orientiert sich an dem individuellen Request. Wenn eine 10 als Wert kommt, dann drosselt der SharePoint Server aktiv die Verarbeitung von Requests, um eine weitere Überlastung zu verhindern.

x-MSEdge-Ref

Auch dieses Feld finde ich interessant, da hier anscheinend der Hostname des SharePoint Frontend Servers enthalten ist, über dessen Name ein Rückschluss auf den Standort möglich ist.

Mein "On-Premises SharePoint" liefert diese Daten anscheinend nicht. Für eine Überwachung wäre gerade der "X-SharePointHealthScore" durchaus interessant mit Nagios, PRTG und Co abzufragen. Vielleicht kann man die Funktion ja einfach aktivieren.

Ich würde mich freue, wenn ein HTTP-Proxy, der SSL aufbricht, solche Werte aus den Antworten einsammeln und für Performance-Reports zur Verfügung stellen würde. Dann würde ein HTTP-Proxy wirklich einen Mehrwert bieten.

On-Premises

Der Counter ist auch bei On-Premises SharePoint-Farmen in der Regel vorhanden. Hier können Sie sogar selbst konfigurieren, wann der SharePoint Server Verbindungen drosselt und welche Performancecounter ereinbezieht

Tipp: Den Wert "X-SharePointHealthScore" kann auch ein Loadbalancer bei seinen synthetischen "HealthChecks" abfragen um die Lastverteilung auf mehrere interne SharePoint Server einer Farm besser zu steuern.

Abfragbare URLs

Ich habe dann natürlich weitere URLs durch einen Fiddler-Trace analysiert, indem ich mit SharePoint und OneDrive gearbeitet habe. Das Ziel waren dabei URLs, die idealweise nur kleine Datenmengen liefern, ohne Authentifizierung arbeiten und keinen aufwändigen "POST" mit Daten benötigen.. Das macht die Nutzung in einem Skript deutlich einfacher. Allerdinge müssen Sie aufpassen, da einige URLs einen "302 Redirect" liefern und ein Invoke-WebRequest dem folgen, wenn Sie dies nicht mit "-Maxredirect 0" unterbinden. Für eine Messung ist es letztlich egal, ob der Webserver einen 2xx, 3xx,4xx oder 5xx Code liefert, solange der Daten liefert und wir eine Laufzeit ermitteln können.

Die URLs sind auf meinen Test-Tenant gerichtet aber das Ändern des Tenant-Namens sollte sie nicht vor unlösbare Probleme stellen.

URL Information Statuscode SP Perfmon Payload

https://msxfaq.sharepoint.com/

Startseite Tenant Sharepoint, liefert einen 302

302 Moved

Ja

1027 Bytes

https://msxfaq-my.sharepoint.com/

OneDrive Startseite, liefert einen 302

302 Moved

Ja

1032 Bytes

https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx

Einfach generiertes JSON Manifest, welches wohl Android Clients laden

200 OK

Ja

1131 Bytes

https://msxfaq-my.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx

Einfach generiertes JSON Manifest, welches wohl Android Clients laden

200 OK

Ja

1134 Bytes

https://msxfaq.sharepoint.com/_layouts/15/WsaUpload.ashx

URL, die im Rahmen des CEIP (Customer Experience Improvement Program) genutzt wird

400 Bad Req

Ja

830 Bytes

https://msxfaq-my.sharepoint.com/_layouts/15/WsaUpload.ashx

URL, die im Rahmen des CEIP (Customer Experience Improvement Program) genutzt wird

400 Bad Req

Ja

827 Bytes

https://msxfaq.sharepoint.com/_layouts/15/images/spmobileandroidappicon.png

App Icon für Android

200 OK

Nein

3279 Bytes

https://msxfaq-my.sharepoint.com/_layouts/15/images/spmobileandroidappicon.png

App Icon für Android

200 OK

Nein

3277 Bytes

Sie sehen sehr schnell, dass die Bilder mit 2689 Bytes für einfache Tests anonym nutzbar sind und SharePoint damit auch wohl wenige Zeit vertrödelt, aber die Zeit dennoch nicht sonderlich viel schneller ist, als bei den anderen URLs. Interessanter ist hier eher die Startzeiten oder das Manifest, bei denen

End2End-HTTP

Mit diesem Wissen habe ich den Code von end2end-http um weitere URL-Templates erweitert und sammle auch die SharePoint-Headercounter und den Namen des Frontend Servers ein. Diese Daten werden zusätzlich in der Debug.CSV mit abgelegt, um später ausgewertet zu werden. Hier ein Beispiel:

"Timestamp","url","httpstatuscode","httpbytes","Status","Message","totalduration","networkduration","avg10","Spiislatency","Sprequestduration","Sphealthscore","frontendserver"
"2019-12-18 15:02:09Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","177","129","129","1","48","3",,"AM3EDGE0317"
"2019-12-18 15:02:11Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","64","32","119","0","32","3",,"AM3EDGE0317"
"2019-12-18 15:02:12Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","551","66","114","1","485","7",,"AM3EDGE0317"
"2019-12-18 15:02:13Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","90","41","107","1","49","5",,"AM3EDGE0317"
"2019-12-18 15:02:14Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","234","49","101","2","185","5",,"AM3EDGE0317"
"2019-12-18 15:02:16Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","57","32","94","1","25","5",,"AM3EDGE0317"
"2019-12-18 15:02:17Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","58","36","88","1","22","6",,"AM3EDGE0317"
"2019-12-18 15:02:18Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","171","53","84","14","118","6",,"AM3EDGE0317"
"2019-12-18 15:02:19Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","104","37","79","1","67","6",,"AM3EDGE0317"
"2019-12-18 15:02:20Z","https://msxfaq.sharepoint.com/_layouts/15/SPAndroidAppManifest.aspx","200","308","OK","","98","40","75","1","58","8",,"AM3EDGE0317"

Ich habe nur die Antwortzeiten noch mal umformatiert.

"totalduration","networkduration","avg10","Spiislatency","Sprequestduration","Sphealthscore","frontendserver"
"177",          "129",            "129",  "1",           "48",               "3",            "AM3EDGE0317"
 "64",           "32",            "119",  "0",           "32",               "3",            "AM3EDGE0317"
"551",           "66",            "114",  "1",          "485",               "7",            "AM3EDGE0317"
 "90",           "41",            "107",  "1",           "49",               "5",            "AM3EDGE0317"
"234",           "49",            "101",  "2",          "185",               "5",            "AM3EDGE0317"
 "57",           "32",             "94",  "1",           "25",               "5",            "AM3EDGE0317"
 "58",           "36",             "88",  "1",           "22",               "6",            "AM3EDGE0317"
"171",           "53",             "84", "14",          "118",               "6",            "AM3EDGE0317"
"104",           "37",             "79",  "1",           "67",               "6",            "AM3EDGE0317"
 "98",           "40",             "75",  "1",           "58",               "8",            "AM3EDGE0317"

Es ist gut zu sehen, dass alle Request immer beim gleichen Frontend Server landen. Der "SPHealthScore ist aber oft über 5 und zeigt eher einen "langsamen" SharePoint-Server" an. Die Daten können z.B. in PowerBI auch einfach visualisiert werden.

End2End-http ermittelt auch den Frontend bei Exchange- Abfragen und hier sieht man oft einen neuen Server mit jeder Anfrage. Im Extremfall sogar aus unterschiedlichen Datacentern.

Page Diagnostics for SharePoint Tool

Wenn es gezielt um SharePoint Online geht, gibt es von Microsoft ein Plug-In für Edge-Browser (ab Version 77) und Chrome. Das Plugin analysiert die Zugriffe des Browsers auf SharePoint-Online Seiten hinsichtlich der Performance. Die Installation erfolgt direkt im Browser über Addons.

Page Diagnostics for SharePoint
https://chrome.google.com/webstore/detail/page-diagnostics-for-shar/inahogkhlkbkjkkaleonemeijihmfagi

Es benötigt dazu natürlich einige Berechtigungen:

Nach der Installation finden sie oben rechts neben der Adressleiste das Icon, mit dem Sie die Analyse starten können. Das AddOn überwacht also nicht kontinuierlich ihre Browser-Aktivitäten, sondern sie gehen auf eine SharePoint Seite und drücken dann Start:

Damit wird ein "Reload" der aktuellen Seite ausgelöst, um die einzelnen Aktionen dann zu verfolgen.

Damit ist das AddOn zwar im Prinzip ein ganz nettes Tool um als SharePoint Entwickler eine einzelne Seite genauer auseinander zu nehmen aber kein End2End-Dauertest.

Schade, dass das AddOn nicht kontinuierlich die Aufrufe überwacht und die Ergebnisse irgendwie auswertbar hinterlegt. So greift das AddOn zu kurz und ermöglicht keine kontinuierliche Überwachung der Performance über einen präparierten Client.

Weitere Links