SharePoint 2010 för Utvecklaren: Att tänka på performance!

Introduktion

Att tänka på performance och skalbarhet är otroligt viktigt i de flesta projekt idag, inte minst när vi pratar om projekt som levereras på SharePoint-plattformen. I det här inlägget tipsar jag lite om vad man som utvecklare bör tänka på när man tar fram lösningar baserat på SharePoint 2010.

Några nyckelord att luta sig mot

Developer Dashboard

För att få en liten koll på hur din SharePoint-lösning mår, både i form av effektivitet och hur mycket systemresurser den kommer att sluka så finns det I SharePoint 2010 ett utmärkt verktyg som heter Developer Dashboard som kommer väl till hands. Är du utvecklare och behöver säkerställa att din lösning inte tar för många resurser eller om den orsakar långa fördröjningar i din portal så är det ett utmärkt tillfälle att slå igång Dev Dashboard.
Läs mer här om Developer Dashboard och hur du kommer igång!

SPMonitoredScope

Om du har följt det första tipset om Developer Dashboard, så bör du fortsätta och kika på SPMonitoredScope som är ett bra alternativ om man vill övervaka anrop som sker I koden och kunna mäta hur lång tid de tar på sig att exekvera. Det här är ett perfekt hjälpmedel som utvecklare för att kunna få en indikation på om vi bör förbättra någonting innan deployment till produktion.
Läs mer här om SPMonitoredScope!

Logga till ULS

Ett av mina nyckeltips när jag utbildar folk I SharePoint 2010 är att alltid logga till ULS! Om vi skickar upp information om vår lösning till ULS loggen, inte minst när vi får felmeddelanden, så ökar vi chanserna för administratörer att kunna hitta vad som gått fel även i produktionsmiljöer. För SharePoint specialister finns det ganska bra verktyg både för att läsa loggarna och för att skriva till loggarna.
Läs mer här om hur Logging funkar i SharePoint 2010!

Disposal patterns

Ni har hört det förr, och ni får höra det igen. Glöm inte att göra Dispose på era objekt!. Många undrar varför man måste göra en Dispose manuellt på t.ex. SPWeb och SPSite objekten i SharePoints API - ett av svaren är att de objekten lutar sig mot en del unmanaged code som alltså ligger utanför .NET motorn - detta innebär att vår kompis Garbage Collectorn inte förstår vad den ska göra med objekten, och således inte gör en automatisk dispose. Det finns så klart många tricks till hur man kan lösa de "problem" som uppstår med detta.
Läs mer här om hur du börjar tänka i rätt banor gällande Disposing i SharePoint!

Fundera över att använda CSS sprites för att minska datamängden mellan klient och server

En alltför sällan benyttjad funktionalitet i många webb-projekt idag är så kallade CSS sprites. Vad det här innebär är att med CSS sprites så lägger man ihop många bildfiler till en enda fil och använder CSS för att tala om för vår markup vilken del av bilden den ska visa när man gör en request. Fördelen med den här approachen är så klart att istället för att ladda ner 200 olika bildfiler för din applikation så laddar man bara ner 1 bild, och därtill så klart CSS-filerna som behövs. Detta medför ofta en snabbare överföring mellan server och klient och kan på ett trevligt sätt skapa en aningen snabbare svarstid.
Läs mer om CSS sprites här!

Minifierade script-filer gör också load-times snabbare

Ibland undrar man varför vissa jQuery eller JavaScript filer ser så svårlästa ut - t.ex. när man öppnar en .js fil och hela scriptet ligger på en enda lång rad. Anledningen till det här kallas minifiering av script, det vill säga möjligheten att ta bort onödika mellanslag, line breaks etc. Detta medför att filen blir aningen mindre och att överföringen mellan klient och server blir snabbare även här. Detta används flititigt i SharePoint 2010, och bör absolut övervägas i dina projekt.
Läs mer här om hur du kan minifiera dina script!

Tänk på hur stor din viewstate blir!

Ett vanligt förekommande problem på en del webbsiter är att utvecklare sällan reflekterar över hur stor ViewState blir. Ett tips är så klart: Tänk på hur ni gör med er ViewState.
Läs mer här om ViewState och SharePoint 2010!

Summering

Att tänka på performance är så klart väldigt viktigt I alla projekt, men tänk på att det måste finnas en balans mellan affärsnytta och performance också - man kan skruva på SharePoint väldigt länge och på väldigt många sätt för att få ut bättre prestanda ur sin farm, men ibland är det läge att överväga om vi låter tekniken ta över affärsvärdet. Ofta har det hänt att man blir efterklok och börjar skruva på prestandan efter man produktionssatt en lösning, men det bästa är att ha allt detta i åtanke redan innan projektet sjösätts. Men vi vet väl alla att det är ganska enkelt att vara efterklok.

Happy Coding :-)