280 likes | 420 Views
SharePoint 2010. Prestanda-optimering. Deep Dive: Tobias Lekman SharePoint Chief Architect. Tobias Lekman. Introduktion. SharePoint Chief Architect, Göteborg Arbetat med SharePoint i 8 år Erfarenhet sedan SP2001, aktiv sedan 2003 och uppåt
E N D
SharePoint 2010 Prestanda-optimering Deep Dive: Tobias Lekman SharePoint Chief Architect
Tobias Lekman • Introduktion • SharePoint Chief Architect, Göteborg • Arbetat med SharePoint i 8 år • Erfarenhet sedan SP2001, aktiv sedan 2003 ochuppåt • Runt 60 SharePoint projekt, mångavariationer • BizTalk, Commerce, UAG, ISA, Navision, AX, SQL… • MCPD, MCTP, MCITP (SharePoint 2007/2010) • V-TSP SharePoint 2010 Microsoft blog.lekman.com @TobiasLekman
Problemställningar • Svårt att anpassa efter fiktiv användning • Infrastruktur spelar roll • Affärskrav kan vara omöjliga • SharePoint är komplext • SharePoint kräver mycket • En webpart kan sänka en farm!
”Lösningen kommer gå lika fort som dess långsammaste komponent”
Nätverk • Kapacitet • Last • Isolering av trafik • Web • Databas • Service Applikationer • Sök • Autensiering • Indexering
Server • Design efter funktion • Tunga läs-operationer kräver mer web-servrar • Tunga skriv-operationer kräver mer SQL IOPS • Tunga tjänster (sök, PowerPivot) kräver ytterligare applikations-servrar • Design efter plats • Global distribution med tunga skriv-operationer kräver lokala farmer
Globala lösningar • Flera farmer • Publicerade service-tjänster • Federering • Replikering • Cache (server, proxy, peer-to-peer)
Security Trimming Workflow Search Content Query Intensity Publishing Collaboration Social Client Access Browsing Frequency
Applikations-databaser • Liten till medium • Medium transaktioner • Gruppera på medium kostnad/prestanda disk • Analytics • Kan bli stor! Profile PerformancePoint BCS PowerPivot App Registry Analytics Word Automation
Content Databaser • Praktisk gräns 200GB • Max support 4TB • Skapa separata databaser för • Site collections med stora listor • Stort antal subsites • Mycket I/O • Säkerhet • Hur lång tid kommer det ta att köra backup?
Sök • Crawl kan bli mycket stor • Stora index • Många transaktioner • Isolera crawl och temp db • Egna diskar! • Snabbaste disken du kan hitta... Admin Properties Crawl
Databas-tips • Konfigurera ”automatic growth” • Defragmentera dina index • Begränsa content db storlek • Isolera loggar • Krymp loggar med backup • Använd quotas
Kontroller på sidan • Navigering • Menyer • Ribbon • Delegates • Säkerhet (trimming) • Publicerings-fält • Sök
Anpassningar • Minifiering • CSS sprites • Resurser på hive • Undik databasen
Listor • Bara för att du kan ha miljoner rader ska du inte ha det... • 5000 plus är stort • Throttle • SQL lock • Kolumner: ”Row Stiching” 35% prestanda-sänkning
kundexempel Hur fel kan saker gå...?
Kundexempel • 3 kunder • alla vill ha personliga vyer • 350, 1500 och 25000 användare • alla har prestandaproblem • Olik approach • CQWP med security trimming • CQWP med audience targeting • Egen kontroll med FAST (CQWP med audience targeting gick inget vidare)
Kundexempel Vad gjorde ingen av kunderna? CACHE!
Kundexempel • 6000 externa användare • 250 interna användare • 3 WFE, 2 APP, SQL Kluster • SSAS OLAP • Teradata Problem: Nätverk, AD, brandväggar, ROLAP