Microsoft SharePoint: Probleme erkennen und beheben statt neue Hardware kaufen

Performance-Probleme in SharePoint können mehrere Gründe haben: Ist der SQL Server richtig konfiguriert? Erzeugt SharePoint unnötig Logdaten?

Microsoft SharePoint hat sich in vielen Organisationen zum Standardtool für die interne Kommunikation entwickelt. Umso ärgerlicher sind Performance- und Usability-Probleme, welche die Mitarbeiter frustrieren und dazu führen, dass das volle Potential von SharePoint nicht ausgeschöpft wird. Wie lassen sich Probleme aber schnell erkennen und beheben?

IT-Verantwortliche prüfen den Status ihrer SharePoint-Installationen in der Regel mit herkömmlichen Tools wie SCOM, Performance Monitor, manuellen Tests oder Feedbackbögen. Diese Werkzeuge können zwar hohe CPU-Auslastung, fehlenden Speicher oder volle Festplatten entdecken, doch nicht deren Ursachen. 

Andreas Grabner,
Technology Strategist
bei Dynatrace

Die Fragebögen oder manuellen Tests geben auch nur ein „Gefühl“ der Benutzer wieder – liefern aber keine technischen Daten, was „gefühlt“ langsam ist. Meist wird zur Verbesserung der Situation einfach zusätzliche Hardware angeschafft, die das Problem zwar behebt, aber teuer ist.

Stattdessen sollten eher die tatsächlichen Ursachen erkannt und beseitigt werden. Dazu muss man verschiedene Seiten, Views, individuell erstellte Webparts oder solche von Drittanbietern in der SharePoint-Umgebung überprüfen, da diese den Hauptteil der Anwendungslogik ausmachen, die meisten Ressourcen verbrauchen und für die Usability der SharePoint-Plattform verantwortlich sind.

Schritt für Schritt zu mehr Performance und Verfügbarkeit

Die erste Frage lautet: Wie gut funktionieren die Windows Server, auf denen die SharePoint Sites laufen? Dazu sind nicht nur die klassischen Messwerte wie CPU-, Speicher- oder Netzwerknutzung zu beachten, sondern auch individuelle SharePoint AppPool-Prozesse. Werden hier Probleme erkannt, gilt es die Ursache herauszufinden. Bei hoher Festplattennutzung sind vor allem folgende Punkte zu untersuchen:

  • IIS: Ist der Webserver mit zu vielen statischen Inhalten beschäftigt, sollte das Ressourcen-Caching entsprechend konfiguriert werden. Dies reduziert die statischen Anfragen von Anwendern, die häufig SharePoint nutzen. Zudem sollten die Log-Einstellungen von IIS und die von IIS geladenen Module überprüft werden.
  • SQL Server: Läuft der SQL Server auf der gleichen Maschine wie SharePoint und vielleicht noch andere Datenbanken? Dann sollte die Konfiguration des SQL Servers sowie das Deployment-Szenario überdacht werden, zum Beispiel indem die Inhaltsdatenbank von SharePoint einen eigenen SQL Server erhält.
  • SharePoint: Hier sind die erzeugten Log-Dateien zu prüfen. Manchmal wird der Loglevel zu Testzwecken erhöht, aber nicht mehr zurückgestellt, wodurch das System unnötig viele Logdaten erstellt, die niemand wirklich benötigt.

Auch wenn die CPU-Nutzung zu hoch ist, kommen SharePoint oder SQL Server als Ursache in Frage. Aufwendige SQL-Abfragen oder Stored Procedures können sowohl am SQL Server zu erhöhter CPU-Auslastung führen als auch in SharePoint selbst, welches eine große Datenmenge zu verarbeiten hat. 

Mehr zum Thema Microsoft SharePoint:

Per Office Web Apps Server auf Exchange, SharePoint und Lync zugreifen

Warum hat Microsoft einige Funktionen aus SharePoint 2013 entfernt?

So richten Sie E-Discovery zwischen Sharepoint 2013 und Exchange 2013 ein

Informations- und Daten-Management in SharePoint 2013 im Griff behalten

Hier sieht man sehr häufig, dass Entwickler von Webparts zu viele Daten von der Datenbank anfordern, diese in der Webpart-Implementierung selbst sortieren oder filtern und dann einen Bruchteil der Daten dem Benutzer in der Webseite zur Verfügung stellen. Oft wird vergessen, dass Datenbanken optimal für das Verarbeiten von Daten sind. Schlechte Kenntnisse der SharePoint API oder von SQL führen aber dazu, dass Entwickler selbst diese Algorithmen in .NET nachimplementieren.

Neben dem CPU-Verbrauch von SharePoint und SQL Server sollte zudem geprüft werden, ob andere Services auf der Box laufen, die den Prozessor beanspruchen. Einige Batch- oder Reporting-Prozesse lassen sich eventuell auf einen anderen Server auslagern. Bei der Netzwerkbelastung sind ebenfalls die oben genannten Bereiche zu überprüfen.

Neben diesen klassischen Methoden des Systemmonitoring muss geklärt werden, welche Komponenten tatsächlich diese Ressourcen nutzen. Auch hier gilt: Erst optimieren, bevor neue Kapazitäten zugeteilt werden. Dazu gehören:

  • Speichernutzung und Garbage Collection: Falls der bereitstehende Speicher nicht ausreicht und der Garbage Collector viele alte Daten löschen muss, wird die Antwortzeit beeinträchtigt und viel CPU-Leistung verbraucht. Daher sollten die Speichernutzungsmuster und die Dauer der Garbage Collection geprüft werden. Ein guter Kandidat für zu viel kurzfristigen Speicherverbrauch sind abermals schlecht implementierte Webparts.
  • Langsame Seiten: Oft ist es einfacher herauszufinden, warum einzelne Seiten langsamer sind, als warum die durchschnittliche Geschwindigkeit sinkt. Greifen auf eine langsame Seite nur wenige Nutzer zu, sollte kein großer Aufwand für ihre Optimierung investiert werden. Stattdessen lohnt es, sich auf die Seiten mit vielen Aufrufen zu konzentrieren.
  • Webparts: Es sollte bekannt sein, von wem die Webparts stammen, welche häufig genutzt werden und wie schnell sie sind. Hier können unzureichende Konfigurationen oder eine schlechte Implementierung Ursachen für Probleme sein.

SharePoint-Überprüfung mit Dynatrace in fünf Schritten

Ein ausreichender Tempo-Check lässt sich in 15 Minuten in fünf Schritten ausführen. Alternativ können Sie auch die Schritte im 15 Minute Tutorial Blog nachlesen oder auf YouTube als SharePoint Performance Analysis Tutorial ansehen:

1.Herunterladen und installieren der kostenlosen Testversion von Dynatrace

Die Testversion gibt es auf der Website von Dynatrace. Da man nach der Registrierung eine .msi-Datei herunterlädt, sollten die Nutzer sichergehen, dass ihr Antivirus-Programm diesen Dateityp nicht blockiert. Anschließend sind die angezeigten Anweisungen zu beachten.

2. Herunterladen und installieren des SharePoint FastPack

Um die Konfiguration von Dynatrace für SharePoint abzukürzen, stellt das Unternehmen ein spezielles FastPack zur Verfügung, das vorkonfigurierte Dashboards und Reports enthält. Es wird als .dtp-Datei heruntergeladen. Nach der Installation lässt sich in Dynatrace der Punkt SharePoint im DropDown-Menü oben links auswählen.

3. Konfigurieren von IIS und SharePoint AppPool

Das FastPack erwartet die Angabe von zwei Agenten: WebServer (IIS) und SharePoint (genauer den AppPool). Anschließend ist der Dynatrace Agent auf dem SharePoint Server zu installieren und zu konfigurieren, um den Traffic zwischen IIS und AppPool vollständig zu überwachen.

4. Last (workload) auf das System bringen

Handelt es sich beim SharePoint Server um ein produktives System oder ein Testsystem mit etwas Last, lassen sich die aufgezeichneten Daten sofort in Dynatrace beobachten. Ist kein Anwender im System, kann der Tester selbst ein paar Seiten anklicken, entsprechende Tools nutzen oder eine Mail an die Kollegen mit der Bitte um SharePoint-Nutzung schreiben.

5. Ursachen für Performance-Probleme identifizieren

Im Monitoring Dashboard lassen sich anschließend die Daten einsehen. Dabei zeigt zum Beispiel der Transaction Flow, wie gut die App funktioniert und wo die Hotspots sind. End User Health gibt einen Überblick, von wo aus die Nutzer auf die Daten zugreifen und wie ihre Erfahrungen sind. 

Application Health analysiert den Status der Anwendung nach Business-Transaktion. Und Infrastructure Health gibt die klassischen Messwerte wie CPU-, Memory-, Disk- und Netzwerkstatus aller Maschinen und Prozesse aus. Damit erhalten Unternehmen schon nach kurzer Zeit wichtige Einblicke in die Performance ihrer Share-Point-Umgebung.

Über den Autor:
Andreas Grabner ist Technology Strategist bei Dynatrace.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Erfahren Sie mehr über Collaboration-Software

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close