Die SharePoint Performance ist eigentlich immer ein Thema. Zumindest habe ich noch keinen SharePoint gesehen, wo sich jemand beschwert hat, dass dieser zu schnell ist. 😉 Aber wie soll man eigentlich die SharePoint Performance messen, bzw. verbessern? Einen Ansatzpunkt bietet hier ganz klar der IIS.
Heute möchte ich euch ein ganz wichtiges Tool vorstellen, mit dem man die IIS Logs vom SharePoint analysieren kann. Allerdings können nicht nur IIS Logs damit verarbeitet werden, sondern auch eine Vielzahl von anderen Daten.
Log Parser ist ein sehr mächtiges Werkzeug, wenn man sich einmal damit beschäftigt hat. Log Parser in der momentan aktuellen Version 2.2 kann direkt bei Microsoft heruntergeladen werden. Der erste Eindruck mag für viele (auch bei mir) zuerst einmal verwirrend sein. Log Parser wird über die Kommandozeile bedient und macht dadurch einen äußert spartanischen Eindruck, der dem Benutzer den Einstieg auch nicht gerade vereinfacht. Allerdings sollte man sich von diesem ersten Eindruck nicht abschrecken lassen, denn dazu ist Log Parser einfach ein zu mächtiges Werkzeug.
Mit Log Parser kann eine beliebige Anzahl von Log Dateien ausgewertet werden. Die eigentliche Aufbereitung erfolgt durch eine Syntax, die man auch bei der Arbeit mit SQL nutzt. Bei IIS Log Dateien sind standardmäßig folgende Felder vorhanden:
- date
- time
- s-ip
- cs-method
- cs-uri-stem
- cs-uri-query
- s-port
- cs-username
- c-ip cs(User-Agent)
- cs(Referer)
- sc-status
- sc-substatus
- sc-win32-status
- time-taken
Diese Felder können nun wie in einem ganz normalen SQL-Statement benutzt werden. Einzig kleiner Unterschied ist die FROM-Klausel, diese zeigt auf einen Pfad wo die Log Datei(en) zu finden ist. Eine erste einfache Abfrage könnte also so aussehen.
Diese Abfrage zeigt die 3 am häufigsten aufgerufene Seiten an. Wie man erkennen kann, sieht die Abfrage wirklich sehr stark nach SQL aus. Es ist natürlich auch möglich die Ergebnisse nicht nur anzeigen zu lassen, sondern diese auch wieder in eine Datei zu exportieren und weiter zu verarbeiten.
Allerdings gibt es auch noch eine ganz nützliche Erweiterung für den Log Parser, nämlich Log Parser Studio. Log Parser Studio ist so etwas wie eine grafische Benutzeroberfläche für den eigentlichen Log Parser. Log Parser Studio kann ebenfalls kostenlos heruntergeladen werden. Weiterhin bietet Log Parser Studio auch schon eine stattliche Anzahl von bereits vordefinierten SQL-Statements, die ohne große Anpassungen sofort genutzt werden können. Es muss nur eine oder mehrere Log Dateien ausgewählt werden, auf dem das SQL-Statement ausgeführt werden soll.
Log Parser Studio zeigt die Ergebnisse auch visuell übersichtlicher an und es besteht die Möglichkeit, die Ergebnisse ohne Umwege grafisch darzustellen.
Nun kommen wir aber zum eigentlichen Thema zurück, nämlich der SharePoint Performance. Jetzt haben wir die nötigen Tools an der Hand, um entsprechende Daten aufzubereiten.
Im Log Parser Studio gibt es bereits ein verdefiniertes SQL-Statement um die langsamsten Seiten herauszufinden. Für eine Aussage zur SharePoint Performance sollte dieses SQL-Statement allerdings noch weiter verfeinert werden. Denn SharePoint nutzt im Hintergrund eine Vielzahl von Web Services etc., die nur eine indirekte Beeinflussung der SharePoint Performance verursachen. Deshalb sollte man sich auf im Browser aufgerufene ASPX-Seiten beschränken, um auffällig langsame Seiten im SharePoint Kontext zu finden. Das zugehörige SQL-Statement für den Log Parser sieht folgendermaßen aus:
SELECT TOP 25
cs-uri-stem as URL,
MAX(time-taken) As Max,
MIN(time-taken) As Min,
Avg(time-taken) As Average
FROM '[LOGFILEPATH]'
WHERE cs-method='GET' and EXTRACT_EXTENSION(to_lowercase(cs-uri-stem))='aspx'
GROUP BY URL
ORDER By Average DESC
Durch dieses SQL-Statement können extrem langsam ladende Seiten gefunden und auch über unterschiedliche Zeiträume („War die Seite schon immer so langsam?“) überwacht werden.
Aber was beeinträchtigt überhaupt die SharePoint Performance? Über diese Frage könnte man wahrscheinlich mehrere Bücher verfassen. Ich möchte nur ein paar kleine Denkanstöße liefern, die je nach Bedarf natürlich verfeinert werden können und auch sollten.
Ein beliebtes Problem warum es zu langen Ladezeiten kommen kann, sind die sog. Windows 32 Fehler. Beim Aufruf einer Seite können dadurch Windows 32 Fehler auftreten, die die SharePoint Performance negativ beeinflussen. Beispiele für typische Windows 32 Fehler sind abgelaufene Passwörter von technischen Benutzern, Unzulässige Funktionsaufrufe, …
Diese Probleme kann man ebenfalls wieder über den Log Parser herausfinden. Dazu nutzt man folgendes SQL-Statement:
SELECT
sc-win32-status As Win32-Status,
WIN32_ERROR_DESCRIPTION(sc-win32-status) as Description,
COUNT(*) AS Hits
FROM '[LOGFILEPATH]'
WHERE Win32-Status<>0
GROUP BY Win32-Status
ORDER BY Win32-Status ASC
Ein weiterer Ansatzpunkt zur Kontrolle der SharePoint Performance sind die protokollierten HTTP-Statuscodes. Jede HTTP-Anfrage wird vom Server entsprechend quittiert. Entweder war die Anfrage erfolgreich (Statuscode 200), oder bei einem aufgetretenen Fehler gibt der Statuscode weitere Hinweise auf den eigentlichen Fehler. Häufig auftretende Fehler sind typischerweise 401 (Unauthorized) oder auch 404 (Not found). Auch hier gibt es wieder ein entsprechendes SQL-Statement:
SELECT TOP 25
STRCAT(TO_STRING(sc-status),
STRCAT('.', TO_STRING(sc-substatus))) As Status,
COUNT(*) AS Hits
FROM '[LOGFILEPATH]'
GROUP BY Status
ORDER BY Status ASC
Wie schon bereits erwähnt, zeigen die Beispiele nur einen Bruchteil der eigentlichen Möglichkeiten. Allerdings sind die ersten Schritte immer die schwierigsten. Deshalb hoffe ich, dass dieser Artikel Euch den Einstieg erleichtert und auch die Angst vor dem Log Parser genommen hat. Durch dieses Tool kann die SharePoint Performance konkret überwacht und eventuelle Probleme isoliert werden. Deshalb ist es auch absolut unabdingbar, dass Ihr selbst mit den SQL-Statements ein bisschen rumprobiert und diese an Eure konkreten Anforderungen anpasst.
In diesem Sinne,
Happy SharePointing…