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: