Waarom Cache gebruiken?
Bij zelfgemaakte web parts binnen Sharepoint kan er al snel een performanceprobleem optreden. Door veelgebruikte data in een webpart te cachen kan dit probleem op redelijk eenvoudige wijze opgelost worden.
Gebruik in de praktijk
Door de cache op de juiste plaatsen binnen een webapplicatie te gebruiken kan de performance verbeterd worden. Dit heeft vooral zin bij overzichten die veel bekeken worden maar niet vaak van data veranderen, omdat bij iedere wijziging de cache geüpdate moet worden. Gegevens verzamelen uit lijsten is een relatief zware en daardoor trage transactie. Door het gebruik van cache kan hierbij een enorme performanceverbetering verkregen worden, omdat dan niet bij iedere postback de lijsten doorlopen hoeven te worden. Een check op wijzingen zou kunnen door LastItemModifiedDate van de lijst te vergelijken met een LastItemModifiedDate opgeslagen tijdens het vullen van de cache.
Er zijn verschillende mogelijkheden voor het gebruik van cache. Hieronder staan de meest gebruikelijke soorten. De uitleg is hier algemeen gehouden. Voor meer gedetailleerde informatie zijn er links naar Microsoft toegevoegd.
Webpart Cache
Web part cache kan zowel Personal als Shared zijn. Personal cache kan alleen benaderd worden door de persoon waarvoor de gegevens zijn opgeslagen. Shared cache kan benaderd worden door alle gebruikers.
Web part cache kan alleen gebruikt worden door dezelfde web part instantie. Dus een webpart van hetzelfde type op een andere pagina is een andere instantie en kan geen gebruik maken van gemeenschappelijke cache.
Bij het gebruik van web part caching heb je de keuze uit de volgende opties: Memory Cache of SQL Cache. Dit moet aangegeven worden in de web.config op de server.
<SharePoint>
<WebPartCache Storage="Database" />
</SharePoint>
Memory Cache
Deze cache gebruikt het ASP.NET-cache-object en wordt bewaard op een Front End Server. Waar rekening mee moet worden gehouden is dat er problemen kunnen ontstaan bij een Serverfarm met meer Front End Servers. De cache is immers opgeslagen in het geheugen van een specifieke server. Om dit probleem te overkomen kan gebruik gemaakt worden van View State, een Hidden Field of Session State. De laatste heeft daarbij de voorkeur.
SQL Cache
Data wordt bewaard in de database. Belangrijkste voor- en nadelen t.o.v. Memory cache zijn:
Voordelen
- In een load ballanced omgeving gebruiken alle web parts dezelfde cache. Omdat ze allemaal gebruik maken van deze database.
- Recycle verwijderd de cache niet.
Nadelen
- Data moet serializable zijn.
- Totale cache van Personal en Shared is gelimiteerd tot 2Mb.
- Is langzamer. Of dit acceptabel is zal een performancetest moeten uitwijzen.
Bij het vullen van de cache kan er een tijd opgegeven worden hoe lang deze bewaard moet blijven. Na deze tijd wordt het cache object leeg gemaakt. Het leegmaken van de cache kan met: WebPart.PartCacheInvalidate () ;
De data van de cache wordt hiermee "Outdated" gemaakt.
Voorbeelden van Code:
Vullen van de web part cache (Een hashtable-object wordt voor 60 minuten bewaard en is door iedereen uit te lezen):
PartCacheWrite(Storage.Shared, sWebPartName + "_" + mySite.ID + ".AllStudentsProducts", htAllStudentProductData, TimeSpan.FromMinutes(60));
Uitlezen van de web part cache:
PartCacheRead(Storage.Shared, sWebPartName + "_" + mySite.ID + ".AllStudentsProducts")
Gedetailleerde uitleg is te vinden op de MSDN pagina's.
ASP.NET Cache
Ook kan er gekozen worden om direct van de asp.net cache gebruik te maken. Deze cache kan ook gebruikt worden over verschillende web part instanties. Hiermee is geen onderscheid te maken tussen personal en shared cache. Dit moet dan gebeuren via specifieke key-namen.
Voorbeeld cache vullen
System.Web.Caching.Cache c = System.Web.HttpRuntime.Cache;
c.Insert(sWebPartName + "." + CurrentWebID + ".sResourcePath", sResourcePath, null, DateTime.Now.AddMinutes(15), TimeSpan.Zero);
Voorbeeld cache uitlezen
c[sWebPartName + "." + CurrentWebID + ".sImagesPath"]
Cache kan leeggemaakt worden met:
c.Remove(wp.sWebPartName + "." + CurrentWebID + ".sResourcePath");
Ook hier is gedetailleerde uitleg te vinden op de MSDN pagina's.
Overige Mogelijke Cache Oplossingen
Vaak is het doel bij het ontwikkelen van webparts bereikt met bovenstaande cache mogelijkheden. Er zijn echter meer mogelijkheden voor het gebruik van cache die ik hier even kort wil noemen.
The Caching Application Block
Dit is een algemene .NET cache en is niet alleen te gebruiken door webapplicaties. Maar ook door gewone .NET applicaties. Meer informatie is te vinden op:
State Service (Session State)
Een State Server is een proces voor het bewaren van de Sesion State. Dit kan op een webserver of op een externe server draaien. Het kan hierdoor gezien worden als een externe opslagplaats voor de sessie. Gebruik Session State als de cache persistent moet zijn over meer Front End Servers. Deze optie is beschikbaar in Sharepoint en kan ingesteld worden via Sharepoint Central Administration.
Meer informatie is te vinden op: