Performance-Optimierung von SharePoint-Plattformen

Performance-Optimierung
von SharePoint-Plattformen
Björn Schneider
Geschäftsführer, ITaCS GmbH
Goldsponsor:
Partner:
Silbersponsoren:
Veranstalter:
Agenda
• Kapazitätsplanung
• Performance- und Lasttests
• Performance-Optimierung
Speicherplatzbedarf
• Speicherung von Dokumenten im SharePoint
–
–
–
–
Ablage als BLOB im SQL Server
Speicherplatz ca. 1,2 - 1,5 x des Filesystemstorage
Kosten/MB ca. 2-3 x höher als bei Fileservern
SLAs beachten! Empfehlung: Content db 50GB max.
• Index und Suchdatenbanken
– Index Server: 5– 12% (x 2,5) der Gesamtgröße des
zu indizierenden Contents
– Query Server: gleiche Größe wie Index Server
– Search-Datenbank: vierfache Größe des Indexes
Empfohlene Limits
Scope
Empfehlung
Auswirkung auf
Web Application
50.000
Farm
Site Collection
250.000
Site Collection
Web Applications
SSP
99
SSP
Application Pools
Web Server
8
Server Performance
Web Application
100
Server Performance
Web Site
2.000
Site View
Items
View
2.000
List View
Lists
Web Site
2.000
List View
Dokumente
Doc library
< 10.000
Web Application
Dokumente
Folder
2.000
Folder View
Dokumentengröße
File
50 MB
Save performance
Indizierte Dokumente (MOSS)
SSP
50 Mio.
Farm
Web Parts
Page
50
Page
Objekt
Site Collections
Web Sites
Content Databases
Sub Sites
Skalierung
Anz. Benutzer /
gleichzeitig
HA
Szenario
Single Server
(SQL Express)
≤ 100 / 10
Nein
Kleine Teams, WSS Sites, WSS
Search
Single Server
(SQL Server)
≤ 500 / 50
Nein
Kleine Portale, Server Search
Separater SQL
Server (1x1)
≤ 1.000 / 100
Nein
Große Portale mit SSP
Medium Farm
(2 x 1 x 2)
≤ 2.000 / 200
Ja
Große Portale mit hohen
Anforderungen an den SSP
≤ 100.000 /
1000
Ja
Große hochverfügbare Portale
mit div. Apps (SSPs)
Farm Typ
Große Farm
(4 x 3 x 2)
Bemerkung
Kapazitätsplanung - Planungstools
– System Center Capacity Planer 2007 & SharePoint
Capacity Planing Tool
Performance- und Lasttest
• Ziel
– Hochrechnung der maximalen Benutzeranzahl
– Ermittlung von Engpässen
– Proof of Concept (PoC)
• Profile
–
–
–
–
Light User (Browsing)  20 RPH
Normale User (Dokumenten Management)  36 RPH
Power User (Forms, Excel, Search)  60 RPH
Extreme User (Robots)  120 RPH
Messmethoden
• Requests per Second (RPS)
– Beste Methode zur Erkennung von Engpässen
– Wie viele Anfragen können maximal bedient werden?
• Messung der Performance von Webseiten
– Page Time aka TTLB (Time to last Byte)
– Hilft bei Überprüfung von Latenzen über WANVerbindungen
• Messung spezieller Operationen
– z.B. Wie schnell kann wie viel Content indiziert werden?
Berechnung des Durchsatzes
• Beispiel
– Contoso hat 80k Benutzer, davon arbeiten 40k wärend
der Businesszeiten (im 8 Stunden Fenster)
– 80k Benutzer, 40k aktiv, davon gleichzeitig 5 bis 10%
– 10% light, 70% normal, 15% power, 5% extreme User
– (10% light x 40k) x 20 RPH = 80.000 RPH
– (70% typical x 40k) x 36 RPH = 1.008.000 RPH
– (15% heavy x 40k) x 60 RPH = 360,000 RPH
– (5% extreme x 40k) x 120 RPH = 240,000 RPH
– 1.688.000 / 3600 (Sec pro Stunde) = 469 RPS
– 469 x 10% peak = 46,9 RPS werden benötigt
Performance- und Lasttest
• SharePoint 2007 Test Data Population Tool
http://www.codeplex.com/sptdatapop
• Lasttest-Tools
– Visual Studio Test Edition
– Visual Studio Team System
• Microsoft Performance Monitor
– Performance Counter für Search
Demo
PERFORMANCE- & LASTTEST
Performance-Optimierung
• Latency components
– Server processing ~ 40%
• SQL processing, # SQL round trips, AJAX processing
– Client processing ~ 45%
• JavaScript, CSS, AJAX requests, HTML load
– Wire transfer ~ 5%
• Bandbreite, Größe des Downloads
• Empfehlungen
– #1 killer of latency = Custom Web Parts
• SQL round trips, excessive client side script
Performance-Optimierung
• Wiederverwendung von bestehendem Client-Code
• Code-Design nach Performance-Gesichtspunkten
– Design Pattern auf MSDN
• Entschlacken der SharePoint Site
– Entfernen von JavaScrips, die nicht benutzt werden
– Reduzierung (KB933823)
• Verwendung von AJAX-Technologien
• Kann den Client-Server-Verkehr deutlich reduzieren (z.B.
asynchrones Postback, partielle Updates)
Performance-Optimierung
• Output Cache mit Profilen
– Ideal für Internet-Sites
– Auf Site Ebene aktiviert
– Cached im RAM
• Object Cache
– Cached im RAM
– 100MB by default
Performance-Optimierung
• BLOB Cache
– Festplattenbasiertes Caching von SQL BLOBs auf
den WFEs
– Reduziert SQL Roundtrips
– Wird in Masterpage aktiviert
<BlobCache location="C:\blobCache"
path="\.(gif|jpg|png|css|js)$" maxSize="10" maxage="86400" enabled="false"/>
Performance-Optimierung
• Application pool recycling
– Fire STSADM Enumsites
stsadm -o enumsites -url http://mywebsite
– SharePoint Warmup Scripts
• Gibt’s in Joels Blog
• HTTP Compression
– Verbessert Latenzzeiten und bringt bis zu 15% mehr
Durchsatz
– Ist bereits für statische Dateien aktiviert (.js, .css)
– .aspx-Dateien können hinzugefügt werden
Festplattenkonfiguration
• Richtige Auswahl des RAID Arrays und der Platten
– Optimieren für “random read/write”
– Viele schnelle kleine Platten
– RAID 10 wo immer es geht
• Proaktives Managen des Datenbankwachstums
– Mit hoher db- & Logfile-Größe starten (z.B. 100GB)
– Nicht auf Autogrowth verlassen, sondern manuelles
Wachstum einstellen (z.B. +1GB)
– Regelmäßiges Shrinken der Datenbanken
Festplattenkonfiguration
• Temp db
– Auslagern auf separate Spindel
– Eine Tempdb pro Core
– Alle Temp-dbs sollten gleiche Größe haben
• Content- und Search db sowie Transaction Logs
ebenfalls auf separate Platten
• Verwenden von mehreren Content Datenbanken für
eine WebApplikation (z.B. 50GB / Content db)
• Bei großen Datenbanken File groups verwenden
– Mehrere Datenfiles pro Datenbank
Festplattenkonfiguration
SQL Server
RAID Level
Bemerkung
Betriebssystem und SQL Files
RAID 1
Mind. 4GB, besser 20GB
Content db
RAID 5 (besser 1+0)
25% frei lassen
Transaction Logs
RAID 1+0
10-15% der DB
Temp db
RAID 1+0
Pro Core eine Datei
Search db
RAID 5
Ggf. File groups verwenden
DB Backup
RAID 0 (oder 5)
Application Server und WFE
RAID Level
Bemerkung
Betriebssystem und MOSS
RAID 1
Mind. 4GB, besser 20GB
Index bzw. Query Files
RAID 5
Index wird 2x gespeichert
Performance-Optimierung – CPU
• WFEs brauchen viel CPU Power
– Ein Quadcore ist schneller als 2 Dualcore CPUs
– Mehrere Kerne sind wichtiger als GHz
– 2nd Level Cache ist sinnvoll
• Application Server
– Anforderungen an die CPU sind zwar hoch,
aber die Auswirkungen sind moderat
• SQL Server
– Auswirkungen der CPU sind moderat
Performance-Optimierung – RAM
• WFEs
– Auswirkung: moderat
– Abhängig von der Anzahl der WebApps
• Application Server
– RAM ist wichtig, denn Indexing braucht viel RAM
– 64 Bit erhöht adressierbaren Arbeitsspeicher
• SQL Server
– Viel Arbeitsspeicher ermöglicht es, die Datenbanken
weitestgehend aus dem RAM zu bedienen.
64Bit-Architektur
• Vorteile
– Bessere Speicherausnutzung und Adressierung
– Chipset: mehr CPUs & Enhanced bus architecture
– 64 Bit akzeptiert „oob“ nur signierte Treiber
• Nachteile
– 32Bit-Treiber können nicht verwendet werden
– Applikationen und Tools funktionieren evtl. nicht mehr
– Kein .NET Framework 1.x verfügbar
• Unbedingt gleiche Architektur für alle SharePoint
Server innerhalb einer Rolle Farm verwenden!
Betriebssytem
• Windows Server 2003 SP2 bzw. R2 liefert
Enhanced Network Pack
– Achtung: Bei Problemen Chimney Offload abschalten!
Netsh int ip set chimney DISABLED
• Windows Server 2008 Next Generation TCP/IP
Stack bringt Verbesserungen im Netzwerkstack wie
– receive window auto-tuning
– compound TCP
– improved routing path detection and recovery
Performance-Optimierung – Netzwerk
• WFEs
– Netzwerkverkehr muss 2x durch die NICs
– Ggf. Trennung von Inbound und Outbound Traffic
– Unbedingt GBit zwischen WFEs und DB!
• Application Server - Auswirkungen: moderat
• SQL Server - Auswirkungen: hoch
Auswirkung durch Verschlüsselung
• SSL-Verschlüsselung
[Client/Server] kostet ca. 6%
(ohne SSL-Beschleuniger)
• SQL SSL-Verschlüsselung
[WFE/SQL] hat einen
marginalen Verlust von ca. 3%
• IPSec-Verschlüsselung
[WFE/SQL] kostet ca. 11%
(ohne IPSec Offloading)
Authentifizierungsverfahren
• Authentifizierungsverfahren haben
unterschiedliche Performance
• Gute AD-Infrastruktur ist wichtig! (4 WFEs pro DC)
• Laut MS Whitepaper* (schnell  langsam)
Anonymous  Kerberos  NTLM  Basic  Forms
• Messung
Anonymous  Basic  Kerberos  NTLM  Forms
*WhitePaper: Additional performance and capacity planning factors
Performance-Optimierung
Zusammenfassung
CPU
RAM
HDD
Netzwerk
Application Firewall
+
-
-
+
Web Frontend Server
++
-
-
++
Application Server
+
+
-
-
Datenbank Server
+
++
++
+
Wo lohnt es sich als erstes zu investieren?
1. Gutes Farmdesign
2. Gigabit Netzwerk
3. CPUs in WFE
4. RAM in SQL Server
5. Festplattenkonfiguration SQL Server
Fragen?
Weitere Vorträge
• Mi, 15:15 - Backup- und Recovery-Strategien
• Do, 10:30 - Veröffentlichung und Absicherung von
SharePoint in Extranet-Umgebungen
• Oder besuchen Sie den ITaCS Stand im Foyer.
Meine Kollegen Stehen für Sie bereit.
Sessionvoting
Ich freue mich auf Ihr Feedback
DANKE!
Wir sehen uns wieder:
Schneller zum .NET 3.5
Developer
Advanced Developers
Conference
In 5 Tagen zum
SharePoint Profi
23.-27. März 2009 in Burghausen
04.-08. Mai 2009 in Köln
Oktober 2009
23.-27. Februar 2009 in Köln
09.-13. März 2009 in München
www.DevTrain.de/Camp
www.ADC09.de
www.SharePointCamp.de
Vielen Dank!
Dein Name
Goldsponsor:
Partner:
Silbersponsoren:
Veranstalter: