I. Mit is cache-elhetünk?
A kérdés nem is olyan egyszerű. Html szinten cache-elni az iwiw esetében nehéz, nagyon sok minden perszonalizáltan jelenik meg, nagyon sok a dinamikusan változó adat. Persze, ha egy nagy forgalmú oldalnál ha csak másodpercekre, de a gyorsítótárában tud az ember tartani tartalmakat, nagyon sokat nyerhet vele. Csak aztán arra kell odafigyelni, hogy nehogy az cache item-ek invalidálása vigye el a sok időt. Ami már majdnem html szintű cache, az a felhasználók által beírt nyers szövegek "parse-olt" verziójának gyorstárazása (linkek, emótikonok felpakolása, stb.).No, de kicsit elkanyarodtam az alap kérdéstől. Szóval html-t cache-elünk, de nem számottevő mennyiségben.A második, jelentősebb cache az iWiW alatt az adat (objektum) cache. Szinte minden adat bekerül a cache-be, csak a nagyon gyakran változó adatok nem. A legfontosabb, hogy az adatbázis tehermentesítve legyen minél jobban, hiszen éppen elég kérést kap olyan funkciók használatával, amelyeknél nincsen lehetőség cache-elésre.
II. Hogyan is cache-elünk?
A képek gyorsítótárazásáról már volt szó, úgyhogy inkább az egyéb cache megoldásainkról írnék. Igazából két nagy csoport van, az in-process cache és az out-of-process cache, hogy melyikben mit cachelünk, az üzleti logikai kérdés volt, és nem a cache-elendő adat típusa határozta meg. Tehát ugyanúgy vannak mindkettőben objektumok, html darabok, stringek cache-elve.in-process cache
Az in-process cache lényege, hogy egy alkalmazásszerver JVM-jén belüli cache-ről beszélünk. Mindegyik alkalmazásszerver magának cache-el, a többi gép broadcast üzenetekben értesül arról, ha valamelyik cache elemet üríteni kell a cache-ből (flush), mert változott, vagy törlődött.
Az in-process cache-re az OpenSypmhony által fejlesztett OSCache-t használjuk, a clusterelt működésben pedig a JGroups segít.
out-of-process cache
Az out-of-process cache lényege, hogy az alkalmazások egy vagy több közös cache szervert használnak, így egy adatot csak egy appservernek kell betöltenie, a többi már tudja rögtön a cache-ből használni azt. Ugyanez igaz az elemek invalidálására is, az egyik appservernek elég flush-olni az elemet a cache-ből, a többi appserver ezután már nem fér hozzá az adathoz. Itt a memcached-et használjuk, iszonyúan ütős, hatalmas teherbírású cucc, tényleg csak ajánlani tudjuk! Van hozzá php-s, java-s, .net-es (C#) kliens API, úgyhogy még az alkalmazott platform sem szabhat határt (igaz, unix/linux környeztben fut csak, habár már készült win32-es verzió, de még nincs sok bíztató adat vele kapcsolatban). Csak egy érdekes adat by leczb: a memcached pillanatnyilag 4000-5000 read req/s tol ki magából, 85%-os hit rate-el (magyarul a kérések 15%-a jut csak el az adatbázisig). A másik érdekes adat pedig, hogy 2-3 nap alatt a memcached szerver forgalma eléri a 2-3 Tbyte-ot...
III. Amit mi hozzátettünk
Az előzőekben leírtam, hogy milyen cache megoldásokat alkalmazunk, valamint hogy körübelül hogyan határoztuk meg a különböző gyorsítótározandó (de szép szó :]) elemeket. Azonban szükségünk volt arra, hogy maga a cache funkcionalitás egy külön réteg legyen az alkalmazásban, könnyen ki és be lehessen rakni alá objektum típusokat, sőt az is legyen megváltoztatható, hogy az objektumok, elemek éppen in-process vagy out-of-process cache-be kerüljenek.Ezen probléma megoldására készítettünk egy saját cache réteget, amelyet összeházasítottunk az adatelérési rétegünkkel. Így nyertünk egy szabadon konfigurálható cache réteget, ahol beállítható akár több in-process és out-of-process cache repository, a különböző repository-k esetbén meghatározható, hogy milyen elemek kerüljenek bele, hány kerülhet bele, FIFO (First-In-First-Out: a legrégebbi elemek) vagy LRU (Least-Recently-Used: a legkevésbé használt elemek) algoritmussal pörögjenek ki a cache-ből az elemek, és hasonló nyalánkságok :).
Röviden ennyi, persze ez egy eléggé gyors áttekintő volt, de remélem érdekes/hasznos sokatoknak.
