Válasz a hozzászólásra

A drupal.hu-n zajlik épp egy nagyon jó kis thread: Adatbázis teljesítmény optimalizálása. A szolgáltató hozzáállása magyar viszonylatban példaértékű, és ez is hozzájárult némileg a motivációhoz, hogy összeszedjem a Drupal 7 cache rendszerével kapcsolatos tapasztalataimat.

Először oszlassunk érdemes kicsit tisztázni a Drupal cache fogalmát. Egyrészt sokannál a cache fogalma kimerül abban, hogy az a pár bekapcsolható izébizé a performance oldalon.

Összességében: Drupal cache nem egyenlő a anonim felhasználóknak bekapcsolható oldal gyorstárral!

A D7-ben eleve nincsen olyan, hogy „bekapcsoljuk a cache-t”. Egy nagyon komplex, többrétű cache-rendszer van, ami az egyes elemek kiszolgálását végzi.

Ezek lehetnek dedikált elemek, mint pl a Menü gyorstár, Token registry. Vagy nem dedikált, hanem egy bármilyen modul által végzett egyszeri gyorstárazási művelet.

Még egy picit mélyebben, megpróbálom egyszerűen összefoglalni: Minden dedikált cache-nek van a Drupalon belül egy definíciója. Ez mondja meg, hogy mi történjen akkor, amikor ezt a cache-t írjuk, vagy olvassuk.
Pont ezek a definíciók teszik azt lehetővé, hogy az összes típusú cachet egységesen írhassuk, olvashassuk. Amit a modulok - illetve természetesen maga a Drupal is - a cache_get() és cache_set() függvényekkel tesznek meg.

Mire kell a cache rendszer?

Egy példa: Egy node megjelenésekor a címkék mellé ki akarunk írni egy számot, ami a node szerzőjének a node tartalomtípusába tartozó olyan tartalmak összege, amely az adott címkével el van látva.

Ez egy közepesen/kevésbé bonyolult lekérdezést jelent, amit kétféleképpen lehet megcsinálni, jól, vagy rosszul. Tegyük fel, hogy megvan a lekérdezés, ott vannak a megfelelő számok a megfelelő címkék mellett. De hogy került oda? Na ez a nem mindegy!

A legrosszabb: A címke kiírásához kapcsolódó preprocess függvénybe írt lekérdezés. Ilyenkor mondjuk egy 10 node teaserből álló, átlag 4 címkével rendelkező lista kiírásához 40!! plusz lekérdezés fog kapcsolódni!

Jó: Hmm.. És itt most viharban lettem, mert egzakt szabály erre nincsen, több módszert kellene kipróbálni, hogy kiválasszam a legjobbat az adott környezethez, feladathoz.

De 1 dolog mindegyik megoldásban benne van: Valamilyen módon fel kell építeni egy objektumot, és eltárolni cache_set()-el. A legkézenfekvőbb egy nodehoz kapcsolódó cache elem felvétele, amiből visszakapjuk a nodehoz kapcsolódó címéket és a kért számot. De meg lehet próbálni közvetlenül abba a cache-ba írni, ami a mező értékeit tárolja - szóval lehetőség van bőven.

Cache a cacheban

Ezek a cache-ok sokszor egymásba épülnek, tehát teszem azt egy nem dedikált cache elem bele fog épülni a page cache-ba (tehát a ki-bekapcsolható anomim oldalcacheba), de például a views dedikált cache-a is ugyanúgy be fog gyógyulni a page cache-ba, tehát anomymus nem fog kapni cache_get-et a viewstól. És ezért emlegettem az elején, hogy Drupalban nincs olyan, hogy "bekapcsoljuk a cache"-t. A legtöbb cache funkciót nem is lehet állítani.

Folytassuk az előző példát:

Kell egy nézet a főoldalra, ami 10 node-ot tartalmaz, benne az általunk elkészített számozott címke mezővel. Szépen beállítottunk cache_setet az eredményünkre nodeonként, és tegyük fel, hogy nem sikerült belegyógyítani a node rendereléséhez használt cache-ba. Hogyan alakulnak a lekérdezéseink bejelentkezett felhasználóknál?

Ebben az esetben 10 többletlekérdezésbe (cache_get-tel kérdezzük le az egy nodehoz tartozó címkék számait) került a 10 node megjelenítése.

És most jön a vudu: Bekapcsoljuk a views gyorstárazását. (a views szerkesztésekor az "Egyéb" szekcióban található) Ez a cache_views_data táblába menti el a lekérdezés kész html eredményét, még az a 10 többletlekérdezésünk is eltűnik, és csak akkor lesz rá szükség, ha a views ezen gyorstárát kell újraépíteni. Tehát a miáltalunk beállított cache a nodeokhoz ezáltal semlegesítődik, az eredménye beleépült a views gyorstárazás eredményébe.

Sőt! Azzal, hogy a views idő alapú gyorstárazását bekapcsoltuk, semlegesítettünk egy rakás más lekérdezéssel járó függvényt, például node_load, user_node_load, comment_node_load.

Mi ebből a tanulság? Bejelentkezett felhasználók esetében a leggyorsabban a views, panels gyorstárazással javíthatunk a teljesítményen.

Ha pedig bekapcsoljuk a gyorstárazást anonim felhasználóknak, akkor a views gyorstár is semlegesítődni fog, mert ilyenkor a cache_page táblából kapja meg a felhasználó az egész oldal renderelt htmljét.

Remélem érthető, hogy miért nem beszélhetünk "cache"-ról a Drupalban.

De akkor miért van mégis egy csomó lekérdezés bekapcsolt anonymus gyorstárazásnál?

Nagyon nem akarok belemerülni a drupal bootstrap folyamatába, de azért néhány példát kiragadnék:

1. Mindenek előtt be kell inculde-olni a modulok php file-jait.
2. Fel kell építeni a változókat, amelyekből például azt állapitja meg a drupal, hogy ez most front_page-e vagy nem.
3. Fel kell építenie egy menüelem-objektumot, amely olyanokat tartalmaz, mint például a felhasználó hozzáférhet-e az adott oldalhoz, vagy nem.
4. A legtöbb esetben álnevekkel dolgozunk. Meg kell állítani, hogy az adott álnév milyen útvonalhoz kapcsolódik, milyen tartalom tartozik hozzá.
5. Fel kell építenie egy $user objektumot. Mert bizony, az anonim felhasználó is felhasználó, van neki neve, vannak jogosultságai, a hozzá kapcsolódó adatokat sokszor használják modulok.

És ezek még csak a core dolgai! Egy gyors mérés szerint egy frissen telepített, majdnem szűz drupal kb 30 lekérdezést produkál anonim userek page cacge kiszolgálásakor. Egy komplexebb oldal esetében ez simán felszaladhat 100 fölé.

És igen, szolgáltatóként ezt marha nehéz lekezelni. Engem két olyan oldallal dobtak ki magyar szolgáltatók, amik az én külföldi, jóval olcsóbb és ugyanúgy shared hosting szolgáltatómnak (hehe, ez egy affiliate link. :)) meg se kottyant. Drupallal nagyon könnyű kinőni egy shared hostingot, és nagyon kevés esetben van arra keret, hogy tényleg igazán elejétől a végéig teljesítményoptimalizáljuk az oldalt. Ilyenkor mindenképpen kompromisszumos megoldás kell, erre Drupal vonalon talán a Boost modul a legmegfelelőbb, ha zömében anonim oldallekérések vannak.