Was beeinflusst die SharePoint Performance ? (Teil 5)

Was beeinflusst die SharePoint Performance ? (Teil 5)

image

Nach langer Pause möchte ich mit dieser Serie fortfahren. Diese Serie bezieht sich auf SharePoint 2010.Mit SP2013 ändert sich, im Bezug auf Performance, nur wenig. Eine Neuerung ist MDS(Minimal Download Strategy). MDS soll beim Update der Seite nur das Nötigste anfordern. MDS funktioniert nur bei bestimmten Seiten, Publishing Seiten mit Pagelayouts gehören z.B. nicht dazu. Hat ein Control auf der Seite kein “mdsCompliantAttribute=true”, wird die Seite ebenfalls nicht über MDS geladen  – auch wenn es als Feature aktiviert wurde. Erkennbar ist MDS auch an der URL:
image
_layouts/start.aspx.
Ein Sandbox-Webpart deaktiviert MDS ebenfalls. Zusammengefasst: Man kann hier in der Regel wenig tun. Weiter in den Layern.

SharePoint

Wir können natürlich nicht die Datenbanken oder den “Code” von SharePoint verändern. Es gibt in der SharePoint Konfiguration den “mehr Performance”-Schalter nicht. Wer den SharePoint-Ressourcenbedarf reduzieren möchte, kann dies ggf. durch Trennung von Serverrollen erreichen. Bester Kandidat hierfür ist die Suche. Denn diese benötigt auf Datenbankebene I/0 und auf Frontendebene CPU. Für die Indizierung des Filesystems kann kein Change-Log genutzt werden, weshalb ein Increment-Crawl dennoch hohe CPU Anforderungen stellt. Ich empfehle nur nachts, bei geringer Useraktivität, das Filesystem zu “durchforsten”.  Darüber hinaus kann durch das Deaktivieren nicht benötigter Services und Service Applications der Ressourcenhunger verringert werden. Da es zwischen den Service Applications aber häufig Abhängigkeiten gibt und man in 95% aller Fälle, bis auf die BI- bezogenen Service Applications, alle benötigt, sind hier die Einsparpotentiale eher gering.
Der Profile-Import sollte, wie das Full-Backup, nicht tagsüber erfolgen.

Über zu große SharePoint Listen habe ich schon im 2. Teil geschrieben. Leider gibt es in SharePoint 2013 keine High-Performance Liste. D.h. man muss immer noch darauf achten, dass die Listen nicht zu groß werden. Das Problem an dieser Stelle: Jede Lösung entwickelt sich – und zunächst sind auch gigantische Listen kein Problem. Mit zunehmender Userzahl und Elementen wird dieses Problem akuter. Schade, hätte in SP2013 verbessert werden müssen.

Entwicklungen

Die größten Performance Hämmer – im negativen Sinn – sind meist von eigenen Entwicklungen verursacht. Farmlösungen, welche die Gesamtperformance beeinträchtigen, sind auch ein Grund für den Trend zu Client-Side Code. Mit dem Javascript Client-Object Model oder über die Webservices(z.B. SPServices) kann auf Inhalte zugegriffen werden. In der Regel sind Client-Side Lösungen performanter, besser. Da sich in Javascript-Client-Side aber keine Business Logic abgebildet werden kann, musste mit SP2013 ein neues Model her, welches gegenüber Farmcode mit geringem Funktionseinbußen glänzt. Das ist mit dem App-Model gelungen. D.h. in aller Regel sollte eine App die Performance der Farm tendenziell weniger belasten, da SharePoint nur noch als “Datenablage” genutzt wird.

Sandbox-Lösungen beeinträchtigen die Farm – werden aber bei zu hohem Ressourcenverbrauch deaktiviert(300pt). In Zukunft wird es wohl keine Sandbox-Lösungen mehr geben.

Ressourcenintensiv sind Abfragen, die über mehre Webs, Listen, Lookups gehen. Wer hierfür die SPSiteDataQuery Klasse verwendet und Performance Probleme hat, solle es mal mit der CrossListQueryCache versuchen und natürlich nur die nötigsten Felder laden. Optimalerweise sind diese indiziert.
Das Iterieren über ganze Webanwendungen, Site Collections ist ebenfalls nicht effizient. Das Disposing von SPSite, SPWeb sollte inzwischen jedem Entwickler bekannt sein. Es macht zudem Sinn, am Ende der Entwicklung, mit dem Tool SPDisposeCheck zu überprüfen ob die Speicherverwaltung nicht noch optimiert werden kann. Bei größeren Projekten empfiehlt sich ein Lasttest. Im Vergleich zu anderen Entwicklungen werden hier Probleme mit der Speicherverwaltung (häufiges AppPool Recycling, AppPool-Crash, hoher RAM-Verbrach, schlechte Performance) sehr schnell ersichtlich. Man könnte hier noch viele Punkte auszählen: customized pages(bis zu 30% gegenüber ghosted pages schlechter), offene Webparts, SearchCoreResult Webpart oder eine Ableitung davon, anstelle von CAML Query(z.B. vom Content Query Webpart). Das sind dann Entscheidungen, die detailspezifisch sind. In dieser Serie soll es um SharePoint-Tuning im Allgemeinen gehen.

IIS

Wer SharePoint die Installation des IIS überlässt, erhält nur die nötigsten Module. Normalerweise sollte man in der IIS-Konsole, abgesehen vom Logging und SSL, nichts direkt modifizieren.
Wer den initialen Zugriff aus SharePoint optimieren möchte, kann die HTTP Compression aktivieren. Diese wirkt nur für HTML, CSS (z.B. Core.js), Javascript (30-40%) – nicht aber bei Bildern.
image
Fazit: Minimale Verbesserung – es gibt aber auch Berichte, wonach die Performance negativ ausgefallen ist. Wer mehrere CPUs hat, sollte es aber aktivieren.

Ein weiteres Thema sind die Application Pools.
Wenn man die PowerShell Scripts aus dem Web verwendet wird für jede Service Application ein eigener Application Pool (mit eigenem User) erzeugt. Das hat für SharePoint im Wesentlichen folgende Vorteile:

Sicherheit: Da ein Application Pool unter einem eigenen User ausgeführt wird, kann u. U. ein Hacker eben mit den Rechten des Application Pool Users arbeiten. Ein Application Pool Benutzer hat dann eben nur Zugriff auf die Webanwendung, Datenbanken etc. die ihm zugewiesen wurde.

Isolation: Habe ich Code, welcher dazu führt, dass der Application Pool gestoppt wird, ist davon nur die Service Application betroffen und nicht die gesamte Farm oder Webanwendung. Der Code läuft in einer eigenen App-Domain.

Einer der wesentlichen Nachteile von vielen Application Pools ist, dass diese immer warm gehalten werden müssen. D. h. bevor ein App-Pool überhaupt eine Seite ausliefern kann, muss dieser ein Teil des .Net, SharePoint-Dlls laden und durch den Jiter jagen, bevor die Seite/Anfrage ausgeliefert werden kann (Ca. 35-60 Sek). Die Empfehlung für den IIS ist es, nicht mehr als 10 Application Pools zu haben. Je mehr ich habe, desto mehr RAM benötigt auch mein Server. Es macht deshalb Sinn sich Gedanken zu machen. Unstrittig ist, dass man pro Webanwendung, pro Central Administration einen eigenen AppPool mit eigenen Usern haben sollte. Bei den Service Applications solle man konsolidieren.  Wer das macht, schafft es ggf. auch einen SP2013 Server mit 12GB (ohne Suche) zu betreiben. Jeder Application Pool muss in best. Abständen neu initialisiert werden. Dabei ist der Service nicht weg, nein – er benötigt nur die bekannten 45Sek. für den Start.

image
Es empfiehlt sich, den Recycle in die Nacht zu legen und ggf. mit einem Monitoring Script die Application Pools warm zu halten. Alternativ zum Monitoring-Script gibt es auch spezielle Tools, welche diese Aufgabe übernehmen können.
Fazit: SharePoint ist nicht lahm. Es sei denn, der App-Pool ist nicht warm.

Einen schönen Freitag,
Tobias Wolter

2 thoughts on “Was beeinflusst die SharePoint Performance ? (Teil 5)

  1. Axel

    Hallo,

    ich finde die Serie zu SharePoint & Performance sehr gut. Viel detaillierter und nachvollziehbarer als so manch andere Beiträge zu diesem wichtigen Thema.
    Eine Anmerkung: Die Verschlagwortung/Kategorisierung ist bei Part 5 missglückt. Wenn man die Kategorie “Performance” zur Filterung nutzt, findet man Part 5 nicht.

    Viele Grüße aus Dresden,
    Axel

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>