Drupal vs. nagy látogatottság

Indul, vagy kimondhatjuk hogy már el is indult a zoom.hu portál, mely nem kisebb célt tűzött ki maga elé, mint az Index.hu és Origo.hu oldalakkal felvenni a hírversenyt. Úgy tudom hogy szép nagy szerkesztőséggel, nem kis (de nem is olyan nagy mint amiről eddig szó esett) pénzzel vágtak bele a dologba. Szerkesztőségi rendszernek Drupalt választottak, amit eddigi tapasztalataim és a magyar Drupalos/rendszergazdai ismereteket ismerve rossz választásnak tartok. Nem azért, mert a Drupal rossz lenne, hanem mert már a mostani indulásból is az látszik, hogy nem tudják hogyan kell üzemeltetni egy ekkora oldalt.

Drupal alapú portált üzemeltettem már jómagam is: a Weblabor és a Drupal.hu is volt már a szervereimen. A Weblabor magában kb. 5000 napi látogató kb. 10.000 oldalletöltésének a kiszolgálását jelentette. Kezdetben ez egy szerverrel volt megoldva, majd a későbbiekben két szerverre lett szétrobbantva a dolog (webszerver és adatbázisszerver), de összességében így is kb. 1 szervernyi erőforrást vitt el a kiszolgálás. A Zoom.hu az Index és az Origo nagyságrendű látogatottságot célozza meg, az Index esetén ez 850.000 látogatás 3.200.000 oldalletöltését, az Origo esetén pedig ennek kb. háromszorosát jelenti. Nagyon durva és buta egyszerűsítéssel ez 32-100 szervert jelent. Ezzel a számítással két gond van, az egyik hogy az alap Drupal kód amit látni lehet az oldal mögött az nem többszerveres környezetre van tervezve így nem skálázható automatikusan ilyen megoldásban, másrészt pedig hogy azért lehet optimalizálni a Drupal üzemeltetésén is, ha valaki ért hozzá. Így is nem kicsi pénzkidobásnak tűnik első ránézésre a dolog.

A hazai Drupal közösségben vannak olyan emberek, akik láttak már hasonló méretű oldalakat kiszolgáló szerver környezetet (hasonló a véleményük mint az enyém), jómagam is ismerem mind a Netvibes, mind pedig hazai vonalról például a Nemzeti Sport Online, vagy a Blikk oldalainak mögött levő architektúrát, illetve azokat a kódokat és megoldásokat, melyek az ilyen környezetekben életképesek tudnak lenni. A Drupal kódját ismerve egy az egyben biztosan nem alkalmas erre a működésre: üzemeltetési szinten nincsen tartalom publikálási folyamat, az újságírók az éles adatbázissal dolgoznak (nem az van, hogy megírják a cikket, majd az kikerül az éles szerverekre), a felhasználók sokáig be vannak léptetve és ez a működtetés nincsen különválasztva az oldal kiszolgálástól, ergo a belépett felhasználók számára a személyre szabott oldalt kell kitenni, továbbá alapból nincsen megoldás a statikus tartalmak külön erre optimalizált szervereken történő hosztolására (átszinkronizálására) sem. És számos ilyen jellegű kisebb-nagyobb probléma van a Drupal kódjával, melyekről tudom hogy megkerülhetőek, de azt is, hogy akik meg tudják kerülni, azok profi Drupal szakemberek (nem olyanok, mint én . A szép nagy látogatottságú Drupal.org vagy SpreadFirefox is Drupal alapokon fut – tehát a feladat semmiképpen sem lehetetlen, csak nem egyszerű. A felsorolt gondok közül pár megoldása nem lesz elegendő, egy jól használható rendszerhez még ezen problémák megoldásánál is több kell (van már szerkesztőségi tapasztalatom is Magyarország.hu és kisebb oldalak kapcsán).

A Zoom.hu üzemeltetői és fejlesztői több hibát is elkövettek, melyek azt mutatják számomra hogy a kellő üzemeltetési tapasztalattal nem rendelkeznek. Nagy hiba például a címlapra kihelyezett szavazás, mert ez azt jelenti, hogy a belépett, már szavazott felhasználóknak más tartalmat kell kiszolgálni, mint amit a nem belépett, vagy még nem szavazott felhasználóknak. Persze így is van cache a dolog mögött, de az ideális az lenne ha a címlapot boldog-boldogtalan mindenféle PHP közreműködés és testreszabás nélkül kapná meg. Kb. tizednyi architektúra kellene. Az olyan alapvető és statikus tartalmak kiszolgálására optimalizált szerverekért ordító dolgok, mint a JavaScript és CSS fájlok, logó kiszolgálása is a Drupal-t futtató szerverről van kiszolgálva, az oldalak tartalmának cache-elése teljességgel le van tiltva, arról nem is beszélve, hogy 17 CSS és 15 feletti JavaScript fájl töltődik le külön-külön, ami még ha már böngésző cache-ből szolgálódik is ki, kb. 30 felesleges, darabonként kb. tized/huszad másodpercnyi (összességében másodpercek!) extra várakozást és szerver terhelést jelent.

A design egyébként alapvetően nem rossz, de a logó még ha ötletes is, alapvető problémákkal küzd (a fejléc billeg a megemelt M betű miatt). A kategóriákat kiemelő túl hangsúlyos sávnak funkcionalitása nem nagyon van. A rovatoldalakon lehetne még bőven csiszolni, helypazarlóak és kiegyensúlyozatlanok. Van egyébként egy kis Indexes designbeli utánérzés, de az alap Drupal design is egész jó, így lehet, hogy ezek a design elemek részben onnan származnak.

A tartalom fő váza teljesen ígéretes, de például a kevésbé fővonalnak számító sport és IT/tudomány rovarok egyelőre nem túl erősek – ezeket illetően valamilyen erősítés nem ártana, ha tényleg az Index és Origo vonal a cél. A blogok bevonása az oldalba még nem tökéletes: a gond az hogy nagyon el lettek dugva az egyes blogok, és hogy nem képeznek különálló egészet. Szerencsésebb lenne egy önálló, erre a célra optimalizált blogrendszer használata, mely mind megjelenésükben elkülönítenék egy kicsit az oldaltól a blogokat, mind pedig jobban ki tudná szolgálni a blogoktól elvárt igényeket. Az Index nagyon-nagyon erős ezen a vonalon, és mivel úgy gondolom hogy ez egy hangsúlyos irány a jövőt illetően, ezért valószínűleg ezen is jó lenne változtatni, ha komolyan gondolja a főszerkesztő a dolgot.

Összefoglalva: az üzemeltetési/fejlesztési vonal szerintem fájdalmas és nagyon kátyús lesz, a tartalmi vonal az indulásnak megfelelő és jó irány lehet. Akarva-akaratlanul az az ember érzése, hogy a fejlesztői csoport nem volt jó választás, ekkora tőkével és célokkal illett volna egy erre méltó, ilyen jellegű referenciákkal rendelkező céget választani, mely már megtapasztalt ekkora látogatottságot és megoldott nagy rendelkezésre állást is.