Am 3. Dezember 2013 fanden zum vierten Mal die SharePoint Days in Berlin statt, an welcher rund 300 Personen teilnehmen. Ich präsentierte dort das Thema “SharePoint 2013 Performance Optimierung”.

Inhalt der Präsentation
Das richtige Architekturkonzept, massgeschneidert für die jeweilige Kundenlösung, ist das Fundament einer erfolgreichen SharePoint-Einführung. Darüber hinaus gibt es zahlreiche Konfigurationsmöglichkeiten auf Ebene Client, Netzwerk, Windows Server, IIS, SQL Server und Storage sowie SharePoint Server, welche die Performance unter Berücksichtigung der Best Practices steigern werden.
Die Zuhörer erhielten wertvolle Informationen für die Optimierung ihrer SharePoint Farmen. Sie sind damit in der Lage, eine höhere Kundenzufriedenheit zu erzielen, was sich nicht zuletzt auch im Servicedesk durch weniger Tickets wiederspiegeln wird.

Dieser Artikel ist gültig für Installationen mit SQL Server 2008 R2 und SQL Server 2012, Windows Server 2008 R2 und Windows Server 2012 sowie SharePoint Server 2010 und SharePoint Server 2013.

Im Web gibt bereits viele Artikel zu diesem Thema. Allerdings hat sich kaum einer die Mühe gemacht, zu erklären, wo und wie die besagten Einstellungen vorgenommen werden müssen. Deshalb habe ich mich entschieden, dies mit diesem Post möglichst ausführlich nachzuholen.

Auf dem SQL Server werden fast alle Daten von SharePoint abgelegt. Da erstaunt es wenig, dass die Performance des SQL Server direkten Einfluss auf die Geschwindigkeit von SharePoint hat. Trotzdem wird dieser Faktor sehr oft ausser Acht gelassen, nicht zuletzt, weil hinter einer Optimierung oftmals grosse Kosten vermutet werden. Natürlich braucht es auch hardwareseitig ein gewisses Minimum an Leistung. Nachstehend einige Tipps um die Performance ohne zusätzliche Kosten spürbar zu verbessern.

Windows Server Performance Options
Standardmässig ist Let Windows choose what’s best for my computer eingestellt. In den meisten Fällen wird der Server für eine schöne Darstellung optimiert, was allerdings bei einem Server ziemlich unwichtig ist. Der Wert kann hier auf Adjust for best performance gesetzt werden:
Rechtsklick auf Computer > Properties > Advanced system settings > Performance > Settings > Visual Effects

Page File Grösse festlegen
Das Page File wird standardmässig durch Windows verwaltet. In den meisten Fällen ist es sinnvoll, die Grösse und den Speicherort selbst zu bestimmen.
Computer > Properties > Advanced system settings > Performance > Settings > Advanced > Virtual Memory > Settings
Die Grösse des Pagefiles sollte dem Faktor 1.5 der zugewiesenen RAM des Servers entsprechen. Beispiel: 8192 MB RAM x 1.5 = 12288 MB Pagefile

Power Plan anpassen
Standardmässig ist der Balanced Mode aktiviert. Für den Serverbetrieb sollte allerdings High Performance genutzt werden, da dieser einen bis zu 15% höheren Durchsatz zulässt.
Navigieren Sie zu Start > Control Panel > Power Options und stellen Sie dort auf High Performance um.

Sollte die Option High Performance deaktiviert sein, dann klicken Sie auf Change settings that are currently unavailable. Anschliessend kann die Änderung vorgenommen werden.

Allocation Unit Size optimieren
Die NTFS allocation Unit Size sollte auf 64K angepasst werden. Die aktuellen Einstellungen können Sie sich anzeigen lassen, indem Sie das Command Line Tool (cmd) mit administrativen Rechten öffnen und folgenden Befehl eingeben:
chkdsk D: (D: entspricht der gewünschten Partition)
Im untersten Abschnitt der Ausgabe finden Sie die gewünschte Information.

Um die NTFS allocation Unit Size für die Partition D: auf 64K zu ändern, setzen Sie folgenden Befehl im Command Line Tool (cmd) ab:
D: /Q /FS:NTFS /A:64K /V:Data /Y
Vorsicht: Mit diesem Befehl wird das Laufwerk formatiert!

Erläuterung
D: = Laufwerksbuchstabe der gewünschten Partition (in diesem Beispiel D:)
/Q = Quick Format
/FS = File System (in diesem Beispiel NTFS)
/A = Allocation Unit Size (in diesem Beispiel 64K)
/V = Volume Label (in diesem Beispiel heisst das Volume “Data”)
/Y = Bestätigt die Abfrage zum Formatieren der Disk

Windows Firewall
Konfiguration der Windows Firewall gemäss http://www.techtask.com/sharepoint2010/windows-firewall-fur-den-sql-server-zugriff-konfigurieren/

Datenbank Volumes
Die Datenbank Volumes sollten in separate LUNs (Logical Unit Numbers) aufgeteilt werden, idealerweise bestehend aus eigenständigen physikalischen Disks.

Priorisierung der Daten bei unterschiedlich schnellen Disks (in absteigender Reihenfolge)

• 1. TempDB Data Files und Transaction Logs
• 2. Content Datenbank Transaction Logs
• 3. Search Datenbanken
• 4. Content Datenbank Data Files

Werden in der Farm vorallem Daten gelesen und weniger geschrieben, dann sind die Positionen 2 und 4 gegeneinander auszutauschen.
Weiter sollten die Transaction Logs der Search Datenbank von den Transaction Logs der Content Datenbanken getrennt werden.

• SharePoint sollte immer auf einem dedizierten SQL Server oder mind. einer dedizierten SQL Instanz betrieben werden.
• Verwenden einer Named SQL Instanz.
• Als Authentifizierungsmethode für die SQL Istanz sollte Windows Authentication gewählt werden.
• Für grössere Suchanwendungen ist eine separate SQL Instanz für die Suche zu verwenden.
• Verwendung des aktuellsten Service Packs und den aktuellsten Patches bei der SQL Server Installation.
• Die SQL Collation für SharePoint ist Latin1_General_CI_AS_KS_WS.
• Erstellung der SQL Datenbanken mit PowerShell, um GUIDs in den Datenbanknamen zu vermeiden.
• Der SQL Service Account benötigt die Rechte Lock Pages in Memory (siehe http://support.microsoft.com/kb/918483/en-us) und Perform Volume Maintenance Tasks (gpedit.msc > Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments > Perform volume maintenance tasks)
• Auto Create Statistics und Auto Update Statistics auf False belassen

Setzen des minimalen und maximalen Server Memory
Microsoft SQL Server Management Studio > Object Explorer > Rechtsklick auf servername\instanz > Properties > Memory
Setzen des Minimum server memory und des Maximum server memory Wertes in MB. Achtung: Beim Setzen des miximalen Server Memory sollten ca. 3 GB für den Betireb Betriebssystems abgezogen werden.

Fill Factor und Backup Compression
Microsoft SQL Server Management Studio > Object Explorer > Right click on servername\instace > Properties > Database Settings
Ändern Sie den Wert des Default index fill factor auf 80 und setzen Sie ein Häkchen bei Compress Backup, um die Backupkompression zu aktiveren.

Max Degree of Parallelism
Diese Einstellung legt die Anzahl Prozessoren fest, welche für die Verarbeitung einer Abfrage (Query) eingesetzt werden.
Ein hoher MAXDOP Wert wird in der Regel eingesetzt, wenn die Anzahl gleichzeitig zu verarbeitender Abfragen eher gering ist. Ist die Anzahl gleichzeitig zu verarbeitender Abfragen eher hoch, wird in der Regel ein tiefer MAXDOP Wert gesetzt.
Da SharePoint hat eine sehr hohe Anzahl an gleichzeitig zu verarbeitenden Abfragen aufweist, ist ein möglichst tiefer Wert zu setzen, deshalb ist der optimale Wert für eine SharePoint Umgebung 1.
Ist der Wert auf 0 gesetzt, kann der SQL Server alle verfügbaren Prozessoren einsetzen, um eine einzelne Abfrage zu verarbeiten.
Microsoft SQL Server Management Studio > Object Explorer > Right click on servername\instanz > Properties > Advanced
Setzen Sie den Wert Max Degree of Parallelism auf 1

Trace Flag 1117
Durch das Setzen des Traceflags 1117 wird das gleichmässige Wachstum aller Data Files gewährleistet.
Navigieren Sie zu Start > Microsoft SQL Server 2008 R2 > Configuration Tools > SQL Server Configuration Manager > SQL Server Configuration Manager (local) > SQL Server Services > SQL Server (Instance name) > Properties > Advanced > Startup Parameters > und fügen Sie am Ende ;-T1117 an.

Datenbankanpassungen allgemein
Pregrow
Vergrössern der Content Datenbank auf die erwartete Grösse um die Fragmentierung zu minimieren.

Autogrowth
Sollte aktiviert blieben. Bei kleineren Datenbankgrössen sollte der Autogrowth Wert auf 256 MB oder 512 MB eingestellt werden. Bei grösseren Datenbanken, ab ca. 5 GB, ist 10% ein angemessener Wert.

Anzahl Data Files
Die Anzahl der Data Files sollte der Anzahl Processor Cores entsprechen (Minimum 4/Maximum 8)

Recovery Model
In den meisten Fällen kann das Recovery Model Simple verwendet werden. Full sollte vorallem dann eingesetzt werden, wenn eine Backupstrategie mit regelmässigen Backups der Transaction Logs geplant ist oder eine High Availability Konfiguration mit Log Shipping oder Database Mirroring vorgesehen ist.

ModelDB anpassen

• Die Initial Size des MDF Files sollte auf einen sinnvollen Schätzwert angepasst werden.
• Die Initial Size des LDF Files sollte auf 25% der festgelegten MDF Initial Size konfiguriert werden. Dabei sollte darauf geachtet werden, dass der LDF-Wert durch acht aus dem MDF-Wert geteilt werden kann.
• Um optimale Wachstumsgrössen zu erreichen, sollte die Autogrowth-Einstellung sinnvoll gesetzt werden. Dieser Wert beträgt in der Regel 25-50% der Initial File Size.

TempDB anpassen

• Die Inital Size sollte ca. auf 25% der Grösse der grössten Content DB festgelegt werden.
• Aufteilung in mehrere Data Files. Die Anzahl der Data Files sollte der Anzahl Processor Cores entsprechen (Minimum 4/Maximum 8)
• Die Data File Size aller Data Files müssen alle die gleiche Grösse haben.
• Der Autogrowth Wert auf 10% der vergebenen TempDB Grösse setzen, jedoch als fixen Wert in MB.

Maintenance Plan
Daily Full Backup der Content Datenbanken inkl. Consistency Check
Transaction Log Backups alle 30 Minuten
Wöchentliches Backup der System Datenbanken

Die SQL Server Data, Transaction Log und Backup Verzeichnisse sind vom Virenscanner auszuschliessen.

• Content Datenbanken sollten nicht grösser als 200 GB sein, da Backups/Restores ansonsten sehr lange dauern können.
• Nicht mehr als 5’000 Site Collections pro Content Datenbank.
• Setzen von Quotas auf SharePoint Web Application Level.

SQL Alias
Auf allen SharePoint Servern sollte anstelle des tatsächlichen SQL Server- und Instanznamen ein SQL Alias hinterlegt werden. Dies ermöglicht zu einem späteren Zeitpunkt auf einfache Art und Weise eine Migration des SQL Servers.
Das Erstellen eines SQL Alias wird hier beschrieben: http://www.techtask.com/sharepoint2010/sql-alias-fur-sharepoint-web-applikationen-erstellen/

Die Auswahl der SQL Collation für eine SharePoint 2013 Installation ist eine kleine Einstellung, die gerne vergessen geht, aber unter Umständen unangenehme Folgen haben kann. Deshalb ist es wichtig, folgende Collations einzusetzen:

Alle SharePoint 2013 Datenbanken müssen diese Collation haben:
Latin1_General_CI_AS_KS_WS

Empfohlene Collation für die SQL Server Instanz (master, tempdb):
Latin1_General_CI_AS_KS_WS
Es werden jedoch auch alle anderen CI Collations auf Ebene SQL Server Instanz ünterstützt. Diese sollten jedoch nur eingesetzt werden, wenn ein besonderer Anlass dafür besteht.

Andere Collations werden offiziell nicht unterstützt.

Im SharePoint Health Analyzer erscheint folgende Meldung:

Title
Built-in accounts are used as application pool or service identities.

Severity
2 – Warning

Category
Configuration

Explanation
Using built-in accounts like Network Service or Local System as application pool or as service identities is not supported in a farm configuration. The following services are currently running as built-in identities on one or more servers:
SPTraceV4(Windows Service)

Die meisten Services können ganz einfach in der Central Administration unter Security > General Security > Configure service accounts umgestellt werden, indem Sie den betreffenden Service auswählen und einen anderen Benutzer zuordnen.

Beim SPTimerService (SPTimerV4) geht das jedoch nicht, weil dieser in der Liste nicht angezeigt wird. Der Benutzer für den SPTimerService kann mittels PowerShell geändert werden. Öffnen Sie dazu die SharePoint 2010 Management Shell mit administrativen Rechten und führen Sie folgendes PowerShell Script aus:

Tragen Sie in der Zeile $SPManagedAccount = “DOMAIN\serviceuser” Ihren eigenen Serviceaccount ein. Dieser muss bereits als Managed Account in SharePoint registriert sein.

Standardmässig werden alle Logs des IIS auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk voll läuft und das OS somit zum Absturz gebracht wird.

Wie die IIS Logs für einzelne IIS Sites verschoben werden können, ist hier beschrieben: IIS Log Files (mittels PowerShell) verschieben

IIS Logs verschieben
Kopieren Sie nachstehenden Code in ein Textfile (z.B. Notepad) und ändern Sie den Pfad in der zweiten Zeile. Speichern Sie die Datei als PS1, indem Sie die Dateiendung von dateiname.txt auf dateiname.ps1 ändern. Führen Sie die Datei dateiname.ps1 auf dem Server, auf welchem die Log Files aller IIS Sites verschoben werden sollen, als Administrator aus.
Das Script erstellt unter dem angegebenen Pfad – in meinem Beispiel D:\Logs pro IIS Site ein gleichnamiges Verzeichnis. Anschliessend wird der Logpfad für jede IIS Site auf das jeweilige Verzeichnis angepasst. In diesem Beispiel wäre dies somit D:\Logs\SiteName

Import-Module WebAdministration
$LogPath = "D:\Logs"
foreach($site in (dir iis:\sites\*))
{
New-Item $LogPath\$($site.Name) -type directory
Set-ItemProperty IIS:\Sites\$($site.Name) -name logFile.directory -value "$LogPath\$($site.Name)"
}

Standardmässig werden alle Logs von SharePoint auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk vollläuft und das OS somit zum Absturz gebracht wird.

Die Logs können sehr einfach per PowerShell verschoben werden. Nachfolgende Befehle sind auf jedem SharePoint Server in der SharePoint 2010 Management Shell auszuführen.

Wie die IIS Logs verschoben werden können, ist hier beschrieben: IIS Log Files (mittels PowerShell) verschieben

Trace Logs verschieben
Die Trace Logs können via Central Administration > Monitoring > Reporting > Configure diagnostic logging verschoben werden, in dem im Abschnitt Trace Logs der Pfad geändert wird. In meinem Beispiel ist der neue Pfad D:\Logs\SharePoint\TraceLogs

Oder Sie führen in der SharePoint 2010 Management Shell folgenden Befehl aus:
Set-SPDiagnosticConfig -LogLocation “D:\Logs\SharePoint\TraceLogs”

Usage Logs verschieben
Die Usage Logs können via Central Administration > Monitoring > Reporting > Configure usage and health data collection verschoben werden, in dem im Abschnitt Usage Data Collection Settings der Pfad geändert wird. In meinem Beispiel ist der neue Pfad D:\Logs\SharePoint\UsageLogs

Oder Sie führen in der SharePoint 2010 Management Shell folgenden Befehl aus:
Set-SPUsageService -UsageLogLocation “D:\Logs\SharePoint\UsageLogs”

Standardmässig werden alle Logs des IIS auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk voll läuft und das OS somit zum Absturz gebracht wird.

Wie die SharePoint Logs verschoben werden können, ist hier beschrieben: SharePoint Trace- und Usage-Logs (mittels PowerShell) verschieben

Die Logs können sehr einfach per PowerShell verschoben werden. Nachfolgende Befehle sind auf jedem SharePoint Server in der SharePoint 2010 Management Shell auszuführen.

IIS Logs verschieben
Navigieren Sie im Server Manager zu der IIS Site, für welche Sie die Log Files verschieben wollen. In meinem Beispiel: TechTask

Erstellen Sie am neuen Ort die Verzeichnisstruktur zum Ablegen der Log Files. In diesem Beispiel D:\Logs\IIS

Öffnen Sie die SharePoint 2010 Management Shell und setzen Sie folgenden Befehl ab:
Import-Module WebAdministration

Passen Sie den PowerShell Befehl zum Verschieben der IIS Logs an. Tragen Sie bei <Sitename> den Namen der IIS Site ein und ersetzen Sie <NeuerIISLogsPfad> durch den Pfad, unter welchem die IIS Log-Files künftig abgelegt werden sollen.
Set-ItemProperty “IIS:\Sites\<Sitename>” -name logFile.directory -value “<NeuerIISLogsPfad>”

In diesem Beispiel sieht der Befehl wie folgt aus:
Set-ItemProperty “IIS:\Sites\TechTask” -name logFile.directory -value “D:\Logs\IIS”

Unter Logging im Abschnitt IIS der entsprechenden IIS Site (in diesem Beispiel “TechTask”) ist jetzt der neue Pfad für die IIS Log Files hinterlegt. Natürlich kann man auch einfach hier den neuen Pfad eintragen, anstelle von PowerShell…

Vor einigen Wochen habe ich eine sehr schön zusammengestellte Sammlung von SharePoint 2010 Best Practices im Microsoft Technet Wiki entdeckt, die sich jeder SharePoint IT Pro mal anschauen sollte. Natürlich verweisen einige Links auf die bereits bekannten Artikel, es hat jedoch auch ein paar sehr interessante Verweise, die sicher noch nicht jeder kennt.
Nachstehend die Links zu verschiedenen Themen:

Performance
Planning
Installation, Removal, Configuration, and Operation
Deployment
Virtualization
Real Life Usage
Backup and Recovery
Development
Search
Upgrade and Migration
Extranet Environments
Farms

An dieser Stelle besten Dank an Margriet Bruggeman.