Probléma: Ha Debian vagy Ubuntu szerveren futtatsz Drupal-t és a session kezeléssel kapcsolatos beállításokat nem állítottad át a php.ini-ben, akkor a Drupal sessions tábla soha nem lesz ürítve, ezért túl nagyra fog duzzadni, napról napra egyre jobban lelassítva a weboldaladat.

Megoldás: A Drupal settings.php-be szúrd be ezt a két sort:

<?php
ini_set('session.gc_probability',   5); 
ini_set('session.gc_divisor',       100);
?>

<?php
ini_set('session.gc_maxlifetime',   200000);
?>

Miért csak Debian alapú szervereken?

Nade mit is csinál ez a két sor és miért kell ezzel külön foglalkozni a Debian alapú szervereken?

Ahhoz, hogy megértsük a problémát, bele kell kicsit mélyednünk a Drupal lelkivilágába.

Nem csak az asztali gépemen fut Ubuntu, hanem szervernek is szívesen használom. Így vettem észre, hogy az f1vilag.hu oldalon, ami egy elég forgalmas site, a session táblában nagyon sok bejegyzés van. Hamar kiderült, hogy a táblából soha nem kerülnek ki a régi sorok, mindig csak az újak kerülnek beszúrásra.

Utánanéztem, hogy ez hogyan lehetséges, és egy kis keresgélés után kiderült, hogy a Drupal a sess_gc nevű függvényében ürítené a táblát. Az is hamar kiderült, hogy ezt a függvényt nem közvetlenül hívja meg a Drupal, hanem indirekt módon, a PHP-t kéri meg, hogy néha hívogassa ezt a függvényt, amikor a PHP azt jónak látja. Ezt egyébként úgy éri el a Drupal, hogy a session_set_save_handler függvény 6. paramétereként megadja visszahívandó callback függvényként a 'sess_gc'-t.

A PHP egy véletlen sorsolással dönt arról, hogy mikor kell meghívni a munkamenet szemétgyűjtőt, ismertebb nevén a session garbage collectort. A fent beállított értékek esetén, minden 100 oldalletöltés esetén átlagosan 5 alkalommal fog végrehajtódni a takarítás.

Ez mint szép és jó, de miért nem teszi ezt meg magától a PHP Debian alatt és miért teszi meg más rendszerek alatt? A választ megkapjuk, ha bepillantunk a php.ini ide vonatkozó részébe egy Ubuntu vagy Debian alatt:

Debian alatt tehát ki van kapcsolva a php beépített session garbage collection funkciója, és helyettesítve van egy ütemezett feladattal (cronjob). Ami viszont csak annyit tesz, hogy a php session fájljait törölgeti félóránként. Ezért nem lesz soha meghívva a drupal sess_gc függvénye és ezért nő a sessions tábla a végtelenségig. A php.ini-ben, mint fent olvashattuk, nem is érdemes visszakapcsolni ezt a funkciót. Inkább a Drupal-ban állítsuk vissza ezt a funkciót, amelynek hatására már rendszeresen meg fog hívódni a sess_gc függvény és nem nő a végtelenségig a sessions tábla.

A múlt heti bejegyzésben arról írtam, hogy egy gyors weboldal miért jelent versenyelőnyt a konkurenciával szemben. Kétféle sebesség probléma lehet, a kliens oldalon akkor van gond, ha a böngésző program nehezen vagy lassan jeleníti meg az oldalt. Szerver oldalon pedig akkor van gond, ha a böngészőnek indokolatlanul sokat kell várnia a szerverek válaszára.

A Drupal boost modul egy szerver oldali megoldás: az anonim felhasználók oldalletöltéseit teszi villámgyorssá.

Tisztán emlékszem a 2. Magyar PHP konferenciára, ott hallottam először a Drupalról. Abban az időben nagyon foglalkoztatott a weboldalak sebességének optimalizálása, azon belül is az előre legenerált statikus html oldalak kiszolgálásának voltam nagy rajongója. Fel is tettem a kérdést az előadónak, hogy a Drupal tud-e ilyet. Ha jól emlékszem, valami olyasmit válaszolt Goba, hogy az alap rendszer nem tudja, de biztosan készíthető hozzá ilyen modul.

Nos, hölgyeim és uraim, a Drupal boost modul egészen pontosan ezt csinálja: előre legyártott statikus html fájlokat szolgál ki az anonim felhasználóknak. Ezáltal teljes egészében kihagyva a buliból a PHP, Drupal, SQL stacket.

Ez a megoldás villámgyors oldal kiszolgálást eredményez, és egyben hatalmas tehertől szabadítja meg a webszervert. Persze vannak hátrányai is a megoldásnak, de előbb nézzük röviden hogyan működik.

A Boost modul működése

Először telepíteni kell magát a modult. Ez fog gondoskodni a statikus html fájlok mentéséről. Létre kell hozni egy „cache” nevű könyvtárat a Drupal telepítés gyökerében, ide fognak kerülni a html fájlok. Végül pedig a .htaccess fájlba be kell másolni egy nagy adag kódot, itt történik a varázslat: ez gondoskodik a html fájlok kiszolgálásáról.

A .htaccess fájlba másolt kód több különböző feltételt figyel, és ha mindegyik teljesül, akkor a Drupal index.php helyett az elmentett statikus fájl kerül kiszolgálásra. Ilyen feltétel például, hogy nem létezik a DRUPAL_UID nevű cookie, azaz hogy nem bejelentkezett felhasználó nézi az oldalt, vagy hogy GET kérésről beszélünk, és nem POST-ról.

Az eredmény: villámgyors oldal kiszolgálás az anonymous látogatók számára.

A cache fájlok érvénytelenítése

Ha egyszer elkészült egy oldalhoz egy statikus gyorstár fájl, és a fent említett feltételek teljesülnek, akkor az bizony ki lesz szolgálva. A kiszolgálás pillanatában ugyanis nincs lehetőségünk mérlegelni, hiszen nem fut le semmilyen Drupal vagy PHP kód. Éppen ezért alaposan oda kell figyelni, hogy mikor kerül érvénytelenítésre egy oldal gyorstár változata.

Először is, van egy beállítható felső idő határ. Ha ennél régebbi a cache fájl, akkor a boost törli az időzített feladatok (cron) segítségével.

Ha egy node oldalról beszélünk, akkor a node módosításakor is törli a cachet. Ha hozzászólás érkezett a node-hoz, szintén megy a cache a kukába. Ha egy node megkapja a „Promoted to front page”, azaz címlapra helyezés státuszt, akkor meg a kezdőlap lesz törölve. Persze ez csak a Drupal alapértelmezett kezdőlapjával működik. Ha saját kezdőlap megoldásunk van, és használni akarjuk a boost-ot, akkor nekünk kell gondoskodni a címlapi gyorstár törléséről.

A taxonómia lista oldalak fájljait is helyesen üríti a modul, amikor kell. Sőt elvileg CCK tartalomra hivatkozás mező használata esetén, ha változik a hivatkozás, akkor is helyesen törlődnek a megfelelő node gyorstárak.

Mindezeken felül persze lehet, hogy szükségünk lesz saját érvénytelenítő kódot is írni. Ha egyedi címlapot használunk, akkor mindenképpen.

Hátrányok

Az egyik hátránya a modulnak, hogy csak az Apache kiszolgálót támogatja teljes egészében. Márpedig maga az Apache is egy elég komoly lassító tényező, mint ahogy múlt héten egy hozzászólásban is írták. Elvileg nginx, lighthttpd és IIS7 használata is megoldható, többé kevésbé. Én ezeket nem próbáltam még.

A másik gond magából a módszerből adódik: mivel kikerüljük a Drupal-t, ezért az alaprendszerbe épített statisztika modul, illetve hasonló analitika megoldások egyáltalán nem fognak működni. Jelenleg egy nagyon izgalmas, saját fejlesztésű modulon dolgozom, amely azonban épít a Drupal mag statisztika megoldására. Ezért sajnos a kettő együtt nem működik.

Szintén a technológiából adódik, hogy a weboldal jobb és bal sávjaiban elhelyezett dobozok tartalma nem mindig frissül, és ezért Boost használata esetén néha furcsán inkonzisztens adatok jelennek meg. Illetve a véletlenszerűen változó dobozok, például 5 véletlenül kiválasztott fórum téma az elmúlt 1 hétből, sem úgy működik, mint ahogy kellene neki.

Mikor megnéztem a forráskódot, megdöbbenéssel tapasztaltam, hogy a Boost modul hatalmas! 280 KB-nál nagyobb a PHP kód mérete. Egyrészt azért ilyen nagy, mert sok kód kell az különböző cache fájl érvénytelenítési esetek kezelésére. Másrészt sok extra dolgot tud, talán feleslegesen is (lásd lent). És elég sok beállítási lehetősége is van. Egyszóval nagy és bonyolult modul, jobban örültem volna, valami egyszerű és nagyszerű megoldásnak.

Egyéb érdekességek

A Boost modul favorizálja a tömörített (gzip) kiszolgálást, méghozzá elég agresszíven. Állítólag némely proxy szerver felülírja a böngésző által küldött HTTP fejlécét, hogy ne fogadjob GZIP tömörített adatot. A modul egy trükkel (IFRAME-ben meghívott GZIP-pel tömörített oldalban lévő javascripttel beállít egy cookiet) megpróbálja kideríteni hogy az aktuális böngésző támogat-e gzip tömörítést, és ha igen, akkor az Accept-Encoding fejléctől függetlenül GZIP-el küldi az adatot.

Van egy beépített web robot is a Boost-ban. Annyit tesz, hogy cron futás alkalmával bejárja az oldalunkat (konfigurálható, hogy ezt hogyan tegye), ezzel előmelegítve a gyorstárat. Mikor van erre szükség? Ha olyan weblapot készítünk, amire várhatóan kevés oldalletöltés érkezik. Ekkor ugyanis a cache általában túl régi lesz, azaz a látogatók többnyire gyorstárazás nélküli oldallal találkoznak majd.

Konklúzió

Nagyszerű modul, ha az ember együtt tud élni a kötöttségekkel: Apache kiszolgáló, nem mindig frissülő dobozok és az anonim látogatói statisztika hiánya a Drupalban. Utóbbi miatt jelenleg én sajnos egyetlen oldalon sem használom. Persze ha egy szerverem nem bírná már a terhelést, akkor nyilván feltenném: inkább lássák a látogatók az oldalt és nekem ne legyen látogatottsági adatom, mint hogy ne is lássák :)

Vigyázat, ez az aktuális világmegváltó agyszüleményem! A Drupal Forms API előtt használtam néhány másis űrlap generáló rendszert is, de volt egy funkció, amivel soha nem találkoztam, pedig szerintem sok különböző weboldal hasznát venné.

Miután egy felhasználó kitöltöti, és a szervernek visszaküldi az űrlapot, ne csak azt lehessen eldönteni, hogy a kitöltés helye-e vagy sem, hanem legyen egy figyelmezetető, megerősítő funkció is. Úgy tudom elképzelni ezt a legjobban, hogy ha hiba helyett csak figyelmeztetést adunk ki egy mezőre, akkor az űrlap ugyanúgy megjelenik mint hiba esetén, kiemelve a problémás elemeket, de alul a submit mellett, lenne egy Igen, biztos ezt akarom checkbox. Ezt bepipálva már lefutna az űrlap _submit függvénye.

Miért van erre szükség? Azért, mert a hibás- nem hibás eldöntése túl nagy felelősség. Néha vannak veszélyes (vagy szinte bíztosan rossz) űrlap kitöltések, amelyeket nem szabad rögtön feldolgozni, de teljesen elvenni sem lehet egy ilyen kitöltésnek a lehetőségét.

Tengernyi konkrét példát tudnék mondani amikor erre szükség van:

• Használtautó kereskedő oldal, az árat ezer forintban kell megadni. Erre a felhasználó beírja, hogy 150000. Persze lehet, hogy ez egy 150 milliót érő használt autó, de azért elég valószínűtlen. Jó lenne erre figyelmeztetni.
• Klasszikus példa, és drupal-ban is számtalan helyen van, a törlés megerősítés (delete_confirm fg.) Ha lenne form_set_warning(), nem kellene plussz egy űrlapot definiálni minden egyes törlés funkcióhoz.
• Linkeket akarunk tárolni. A http://www.example.com már bent van a rendszerben, mikor valaki hozzá akarja adni a http://example.com–ot, vagy a http://www.example.com/index.php-t.

Persze, most is el lehet érni ezt a funkcionalitást Drupal-ban (lásd delete_confirm), de csak hegesztéssel, egy form_set_warning-al sokkal elegánsabban meg lehetne oldani ezeket a helyzeteket. Ráadásul, amennyire ismerem a Forms API lelkivilágát, ezt nem is lenne túl nehéz beleimplementálni jól.

Kiváncsi vagyok a véleményetekre, nálatok is felmerültek már ilyen igények?