10 Gründe, warum der SharePoint langsam ist

David Schneider
david.schneider@isolutions.ch
http://www.balkongriller.ch
@fiddi
CTO bei isolutions AG
Bern und Zürich
Speaker

3

• Web Front End Server
• ab 16 GB RAM, 4 Core CPU
• SQL Server
• ab 16 GB RAM, 4 Core CPU
• physikalisch ist besser
• Überwachung mit Performance Monitor
• Average % Processor Time: < 60%
• Available Memory: > 50% free
• Disk Read/Write/Sec: < 15 ms
• Network Latency Output Queue Length: 0
6
#1: Sizing

7

• SPWeb oder SPSite werden nicht disposed
• SPDisposeCheck
• Locking Issues, Memory Leaks, etc.
• werden bei Load Tests sichtbar
• SharePoint ist kein RDBMS für grosse Datenmengen
• Viele Liste, viele Vernüpfungen
• SharePoint 2013 App Model entlastet Server
• SharePoint Bounderies beachten
• Large Datebase, large site collection, large list, large ACL
8
#2: Developer

• Vor Go Live
• Auf produktiven Plattform
• Erwartete Benutzermenge simulieren
• Ziel festlegen (z.B. 100 Benutzer, Antwortszeit < 1 Sekunde)
• Tools
• Visual Studio Load Testing Kit
• WAPT
• Mögliche Erkenntnisse
• Memory Leaks
• CPU intensive Web Parts
• Locking Issues (Deadlocks)
9
Load Tests

• Client Side Object Model kann viele Requests zur
Folge haben
• Anzahl Requests im Auge behalten
• Nur notwendige Daten laden
• ExecuteRequest() minimieren
• Tool: Fiddler oder Dev Tool Bar
10
Client Side: Anzahl Requests pro Page Load

11

• Cross Site Rollups und Content Query Web Parts
• durch Content by Search Web Part ersetzen
• Startseite entrümpeln
• Cache der Informationen
• Custom Navigation
12
#3 Slow Queries

• Informationen zum aktuellen Request
• Stack Trace
• SQL Queries
• ULS
• Ein & Ausschalten via PowerShell für die
gesamte Farm
13
Developer Dashboard

14

• Physikalisch besser
• Durchsatz der Storage (in IOPS)
• pro GB Content DB: 0.75 - 1 IOPS
• pro GB tempdb, Search und Transaktionslog: 1.5 - 2 IOPS
• Total pro GB Content: 2 IOPS
• Disk Konfiguration
• Priorität bzgl. Performance TempDB, Transactional Logs, Search DB, Content DB
• Pro Core ein Data File (mind. für TempDB)
• NTFS File Allocation Unit Size >= 64KB
• Pre Allocate Content Databases
• Netzwerk Latency
• zwischen SharePoint Server und SQL Server < 1 ms
• Achtung bei Firewall zwischen Tiers
15
#4: SQL Server

16

• Version von Browser, Office, Betriebssystem
• Enterprise Client
• VDI Client
• Anti Viren Software
• Scan der JS Dateien
• «Auto Detect Proxy Settings»
• Browser Render Time
• Page Optimization
• Caching
• Hardware und Driver
17
#5: Client

18

Im Hintergrund laufende Jobs verlangsamen die Farm
• Crawling
• Backup
• Profile Import
• Timer Jobs
• Large List Operations
#6: Batch Jobs

20

• Client
• Ressourcen (Bilder, CSS, JS)
• Max-Age und Expiries Flag
• BlobCache
• Ressourcen werden auf der Disk auf dem Front End Server zwischengespeichert
• Output Cache
• Gerenderte Page wird im RAM gespeichert  nur für anonyme Zugriffe
• Object Cache
• Datenbankabfragen cachen
21
#7: Caching

• 304 Antworten: Client fragt Server, ob sich die
Ressourcen geändert haben
• BlobCache einschalten (max-age=«86400»)
22
Fiddler

23

Nach dem Recycle des Application Pools ist der erste Zugriff langsam
• Geplante Recycle in der Nacht  Warm Up Script
• Ungeplant  Out of Memory, Fehler
• Warm Up Script ruft jeder Site einmal auf
z.B. https://spbestwarmup.codeplex.com/
24
#8: Warm Up Script

25

• Bandbreite
• 100kbit für Information Worker
• 10kbit für Facharbeiter
• Firewall
• Proxy Server
• Bei «Automatically detect proxy settings» wird beim Öffnen von Office immer noch
Proxy.pac gesucht
• Authentication
• Kerberos ist am schnellsten
• Fehlkonfiguration
26
#9 Netzwerk

Symptome
• Zugriffe alle x Minuten langsam
• ULS: (SPCertificateValidator.Validate). Execution Time=xxx
Ursache
• Zertifikate können nicht überprüft werden. Teilweise kann die CRL nicht geladen werden.
Lösung
• Microsoft: http://support.microsoft.com/kb/2639348
• Weitere Optionen: http://blogs.msdn.com/b/chaun/archive/2014/05/01/best-practices-for-
crl-checking-on-sharepoint-servers.aspx
27
Certificate Validation

28

Office 365 (SaaS)
Windows Azure (IaaS)
Fakt #1: Die Cloud skaliert besser
Fakt #2: Die Cloud skaliert schneller
Fakt #3: Microsoft weiss, wie SharePoint betrieben wird
Fakt #4: Best Practices einhalten. Office 365 verzeiht keine Hacks
29
#10 On Premise

Vorgehen
30

31
Messkriterien
Latenz Durchsatz
Datenvolumen Zuverlässigkeit

32
Welche Faktoren beeinflussen die Performance?
Server
Memory, CPU und Disk
SQL Performance
IOPS auf SAN
Custom Code
Network
Network Infrastructure
Proxy Server
WAN Latency
Compression
Client
Browser Render Time
Page Optimization
Caching
Hardware, Driver, OS and
Browser Upgrades

URL: Welche Sites (URLs) sind betroffen?
User: Welche Benutzer sind betroffen?
Ort: An welchem Standort treten die Probleme auf (LAN, Remote,
etc.)?
Netzwerk: Wird der Traffic über einen Proxy geroutet?
Client: An welchen Clients treten die Probleme auf (Workstation, VDI,
BYOD, etc.)?
Time: Tritt das Problem nur sporadisch oder zu einer bestimmten
Uhrzeit auf?
Anwendung: Ist das Öffnen oder Speicher eines (Office-) Dokuments
langsam?
33
Eingrenzen

Performance Cheat Sheet
Alle Benutzer
betroffen?
Berechtigungen auf
Draft Elemente
(Master Page, etc)
Alle Standorte
betroffen?
Bestimmter
Zeitpunk
Nur Morgens:
Warm Up Script
implementieren
Fiddler zeigt
viele Requests
BlobCache
konfigurieren
Local Intranet Zone
URL
Ja
Client
Deaktivieren von
Anti Viren Software
Browser,
Betriebssystem und
Anwendung
aktualisieren
Group Policies
deaktivieren
Developer
Dashboard
Code Review
durchführen
Custom Code
Neue Web App
ohne Custom Code
erstellen
Server
Performance
CPU und RAM
(PerfMon) auf
SharePoint Server
Latenz zw. SP und
SQL Server (PING)
CPU, RAMund SAN
auf SQL Server
Cross Siteund Site
Collection Abfragen
durch Search
ersetzen
Langsame Leitung
oder fehlerhafte
Netzwerk
Konfiguration
Proxy oder Firewall
WAN Accelerator
deployen
Group Policies
überprüfen
Regelmässigkeit der
langsamen Zugriffe
herausfinden
ULS und Eventlog,
Timer Job, Search
Crawl, Zertifikate
Viele Benutzer
Memory Leak oder
Locking Issue
Ja
Mit Blank
Installation (keine
Enterprise Client,
kein VDI) testen
Kerberos an Stelle
von NTLM
Closed Web Parts
Slowest Pages
Report
Pageoptimieren

35

Health Analyzer Rules
• Recycle der Application Pools wegen Memory Limits
• Datenbanken mit alten/fragmentierten Index Statistics
• Search mit fragmentierten Index
Slowest Page Report
• Central Administration -> Monitoring -> Reporting -> View Administrative Report
• Ggf. Timer Job «Microsoft SharePoint Foundation Usage Data Processing» aktivieren
• Eingrenzen nach Web App, Web Front End Server oder Page
HTTP Request Throttling
• Job checkt CPU, Memory, Request Queue. Bei schlechten Werten, werden Requests
abgebrochen
36
Central Administration

• Teil des SharePoint 2010 Administrative Toolkit
• Generiert Reports über
• Kapazität von CPU, RAM und SQL Server
• Performance
• Verfügbarkeit
• Usage
• Reports können Customized werden
37
SharePoint Diagnostic Studio

• Meldungen im Event Log
• ULS nach nach grossen Werten für «Execution
Time» durchsuchen
• Ggf. auch auf Application Tier
38
Logs

Think out of the box
• Fehlerhaftes Netzwerkkabel zwischen Core
Switches führten zu Paket-loss zwischen
SharePoint und SQL Server.
• Alter VMWare Treiber für Netzwerkkarte hat fast
alles RAM der SharePoint Server beansprucht.
• Ohne Reverse Lookup Zone dauerte das Öffnen
eines PDFs 15 Sekunden.

• PerfMon
• Fiddler2
• http://fiddler2.com/
• Add Ons für Fiddler
• http://fiddler2.com/add-ons
• WireShark
• http://www.wireshark.org/
• Sysinternals Process Monitor
• http://technet.microsoft.com/de-ch/sysinternals/bb896645.aspx
• Microsoft Message Analyzer
• http://www.microsoft.com/en-us/download/details.aspx?id=40308
40
Tools

• Microsoft TechNet Capacity management and sizing for SharePoint Server 2013
• http://technet.microsoft.com/en-us/library/cc261700.aspx
• SQL Server 2012 Best Pratices für SharePoint Server 2013
• http://www.techtask.com/news/sql-server-2012-best-practices-fur-sharepoint-server-
2013/
• SharePoint 2010 Administrative Toolkit (SPDiag)
• http://technet.microsoft.com/en-us/library/cc508851
41
Weitere Informationen

Besten Dank – schön warst Du dabei!

David Schneider, isolutions AG, CTO
Kontakt
E-Mail david.schneider@isolutions.ch
Blog http://www.balkongriller.ch