Aki ismeri az ASP.NET cache szolgáltatásait és tudja, hogy a SharePoint az ASP.NET-re épül, annak számára nem újdonság, hogy a SharePoint is támogatja az output cachinget és az object cachinget. Amit viszont nem tud az ASP.NET, de a SharePoint igen, az a blob cache.
Tudvalevő, hogy a SharePoint a megjelenítéshez használt fájlok egy részét fájl rendszerben, más részét pedig adatbázisban tárolja. A fájl rendszer gyors, az adatbázis lássú. Ezért aztán inkább azt szeretjük, ha a fájl rendszerből tudja a rendszer kiszolgálni a kéréseket. Különösen érdekes ez akkor, amikor sok apró fájlt kell visszaküldeni a kliensre, mint például az apróbb képek, stíluslapok és kliens oldali szkript fájlok.
Nevével ellentétben elsősorban ezeknek a tipikusan ritkán változó apró fájloknak a gyorsítótárazására találták ki a blob-, vagyis binary large object cache-t. Ha ezt bekapcsoljuk, akkor a kliens a webszerver fájl rendszerében közvetlenül kaphatja meg az ott tárolt fájlokat, nem kell értük elmennie a kérésnek egészen az adatbázisig.
Bekapcsolni nagyon egyszerű, web.config-ot kell módosítani. Az alábbi sztringet megtaláljuk a fájlban telepítés után, csak állítsuk az enabled tulajdonság értékét false-ról true-ra:
<BlobCache location="C:blobCache" path=".(gif|jpg|png|css|js)$" maxSize="10" enabled="true" />
A location értelemszerűen az a mappa, ahova a gyorsítótár kerül. Ezt célszerű nem az alapértelmezett helyén, a C:blobCache mappába tenni, bátran vigyük át másik meghajtóra.
A path egy reguláris kifejezés, nyugodtan átírhatjuk, alapértelmezés szerint a gif, jpg, png, css és js végződésű fájlok kerülnek a gyorsítótárba, de bővíthetjük a listát.
A maxSize paraméter a cache mérete gigabájtban, nem aprózták tehát el.
Itt ugyan nem szerepel, de létezik egy max-age attribútum is, ahol megadhatjuk, hogy a kliensek hány másodpercig tárolhatják el ezeket a fájlokat. Ez alapértelmezés szerint 86400, tehát 24 óra.
Mindezt web applicationönként állíthatjuk, tehát készüljünk fel arra, hogy esetleg több helyen is kell módosítanunk telepítés után. A Central Admin Site például tipikusan olyan, ahol ezeket a fájlokat nyugodtan lehet gyorsítótárazni, az éles publikus szerverünk meg aztán végképp. A fejlesztői web applicationre viszont a kevesebb debuggolás érdekében nem érdemes bekapcsolni. Nem árt tudni, hogy draft és checked out állapotban lévő fájlokat a rendszer nem cache-el.
A cache-t természetesen lehet üríteni is, ám itt jön az igazi csavar, az opciót ugyanis nem web application, hanem site collection szinten vezették ki a felhasználói felületre. Ehhez tehát:
- Navigáljunk el a Site Settings oldalra, majd ott kattintsunk a Go to top level site settings linkre.
- A Site Collection Administration oszlopban kattintsunk a Site collection object cache linkre. Ez nem azt jelenti, hogy a blob cache és az object cache ugyanaz. Ez azt jelenti, hogy a blob cache nem kapott saját menüpontot, hanem ide dugták az ellenség megtévesztése érdekében.
- A Disk based cache reset opciónál kattintsuk be a Force this server to reset its disk based cache opciót. Vigyázat, ez az egész szerver összes webalkalmazásának gyorsítótárát törölni fogja!
Tehát bekapcsolni web application szinten lehet, az opciót site collection szinten találjuk meg, de az egész szerverre vonatkozik. Az egész farmra vonatkozó törlési lehetőséget pedig csak az object cache kapott. Igazán logikus, nem?
Balássy György szakmai blogja 