Monthly Archive for 2008. április.

Drupal vs. nagy látogatottság

Published on április 17, 2008 in közlemények, webadmin és webfejlesztés. 55 Comments

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.

Zoom.hu

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.

Webalkalmazások hosztingja

Published on április 16, 2008 in webadmin. 20 Comments

Alkalmazásaink hosztingját illetően ma több választás is áll előttünk. Hazai hoszting szolgáltatók, külföldi hoszting szolgáltatók, és újabban az Amazon és Google ezirányú szolgáltatásai csábítanak. A konkrét döntés jelentősen befolyásolhatják az adott hosztolni kívánt alkalmazás kívánalmai, de megpróbálom röviden összefoglalni ezirányú véleményemet a Google ezen a piacon történő megjelenése kapcsán. Mivel jómagam is egy hoszting céget vezettem több éven át (már nem), úgy érzem hogy elég jó rálátásom van a helyzetre.

Hazai hoszting szolgáltatók

A legalja valahol havi 500 Ft – 1000 Ft környékén kezdődik, ezek azok a szolgáltatók, akikkel nem érdemes szóba állni, ha valaki komolyan veszi magát. Ezen az áron a magyar piacon nem lehet minőségi szolgáltatást nyújtani – aki ezen az áron nyújt szolgáltatást, az vagy “egyetemista” viszonylag kevés tapasztalattal hoszting terén, vagy nagyban űzi, de ekkor is nagyon minimálisan nyújt. A többéves ezirányú tapasztalatom azt mutatja, hogy ha mázlista valaki, csak akkor nem lesz gondja, hosszabb (akár több napos) leállások, félrekonfigurálások, elérhetetlen szerverek és ügyfélszolgálatok jellemzőek erre a körre. Nincs, vagy minimális szintű backup van kínálva, kiesés esetén még ha visszafizetik is a havidíjat (előfordul hogy a szerződésben arányos visszafizetés szerepel – fél havi leállásnál 250 – 500 Ft visszafizetése elég komolytalan) akkor sem igazán vagyunk kárpótolva a kiesésekért. A jellemző tárhely 1-2 GB.

A minőségi szolgáltatók havi 5000 – 10.000 Ft környékén kezdődnek, itt már elérhető és barátságos ügyfélszolgálatra, segítőkész rendszergazdákra is számíthatunk. Ezen az áron se gondoljunk azonban csúcsszolgáltatásra, kiesés itt is előfordulhat, még ha azt már igyekeznek megelőzni a szolgáltatók jó minőségű hardver beállításával. Komolyabb környezet kialakítása (magas rendelkezésre állás, több szerveres környezet) itt sem igazán megoldható. A jellemző tárhely 1-10 GB.

Igazán komoly szolgáltatást akkor éri meg vásárolni, ha komoly üzletről van szó, itt már számunkra dedikált szervereket kapunk, a minimum itt olyan 50.000 Ft lehet, de a határ a csillagos ég (egy szerver elhelyezése BIX-re kötve 15000 – 20000 Ft, magas rendelkezésre álláshoz nem árt 3-4 szerver is, nem beszélve a backupokról, és a rendszergazdák költségeiről). Ezen a szinten jól képzett rendszergazdákat és rendszerünk felépítéséhez tanácsadást is kapunk, kaphatunk. A tárhely mérete a csillagos ég.

Természetesen azért, mert valaki elkér 3.000.000 Ft-ot egy szolgáltatásért havonta, nem feltétlenül lesz az jobb, mint ha a havi 500 Ft-osat vásárolnánk meg – nézzünk utána a referenciáknak.

Külföldi hoszting szolgáltatók

A külföldi hoszting szolgáltatókat illetően már viszonylag kisebb tapasztalatom van. Ezeknél a szolgáltatóknál is megvannak a különböző szintek, külföldi szolgáltató elérése ha baj van, akkor komoly nehézségekbe ütközhet (vagy drága lesz a nemzetközi telefonköltségek miatt). A fizetés jellemzően bankkártyával történik, és az itthon elterjedt elektronikus bankkártyákat nem, csak a dombornyomottakat fogadják el. Kérték már azt is, hogy küldjek személyi azonosítóról fotót, vagy szkennelt képet. A szerverek mivel a tengeren túlon vannak, jellemzően egy nagyon kicsit lassabbak lesznek, vagy kisebb adatforgalmat fognak tudni lebonyolítani, mint hazai társaik.

Minőségi, de backup nélküli szolgáltatást amerikából kaphatunk havi 1000 – 2000 Ft összegért, s ebben akár TB szintű tárhely is benne foglaltatik, azonban biztosan limitált az adatforgalom mennyisége (mondjuk a tárhely tízszerese, jellemzően átlag használatra teljességgel elfogadható). Speciális szerver beállításokra, egyedi igények megoldására ne számítsunk, bár lehet, hogy részben – ha értünk hozzá – pár dolgot meg fogunk tudni csinálni.

Ennél jobb, de nem sokkal drágább szolgáltatásról, ahol már backupot és nagy rendelkezésre állást is garantálnak, nincsenek tapasztalataim. Komoly (de még 1 szerverből álló) szolgáltatásra kértem már árajánlatot, ez jellemzően drágábbra jött ki, mint egy hazai megoldás.

Amazon

Az Amazon nemrégiben kezdte el nyújtani speciális, nagy rendelkezésre állású környezetét, az Amazon EC2-t. A szolgáltatás igénybevétele igényel rendszergazdai ismereteket, ha már előre összerakott megoldást választunk, akkor is. Kis forgalomnál inkább egy minőségi külföldi vagy hazai szolgáltató választás éri meg, nagyobb forgalomnál el lehet gondolkodni az igénybe vételén. Bár az EC2 a SimpleDB-vel kínál adatbázis szerver jellegű megoldást, ez kicsit túl butára sikerült, nem igazán alkalmas komolyabb feladatokra. Ez persze még bőven fejlődhet.

Statikus adatok tárolására (akár képekről, akár személyes backupunkról beszélünk) mindazonáltal kiváló megoldást nyújthat az EC2, ahogyan a Twitter is az Amazon szolgáltatását veszi igénybe erre a célra a profilképek kiszolgálásához.

Google

A Google pár hete jelentette be a Google Apps Engine-t, mely egészen más a korábbiakhoz képest. Jelenleg Python nyelven lehet alkalmazásokat írni, és egy konkrét alkalmazáskönyvtár ár rendelkezésünkre. Kapunk adatbázis szerver megoldást is, mely a Google saját megoldására épít. A Google Apps Engine minden üzemeltetési feladatot levesz a vállunkról, teljesen elrejtve előlünk a konkrét környezetet, ahol az alkalmazásunk futni fog. Szinte egyáltalán nem kell foglalkoznunk a látogatók számának növekedésével sem, a rendszer megoldja a háttérben a skálázást is.

A megoldás nagyon jól hangzik, de vannak gondok is vele. Míg a lehetőségeink nagyon jók, gyakorlatilag a Google-hoz kötjük az alkalmazásunkat ha ezt a környezetet választjuk. Direkt ehhez igazodóan kell leprogramozni a feladatot, és nem fogunk tudni költözni, nincsen hosztoló cég alternatíva. Erős kötöttséget jelent még a Python programozási nyelv is, hiszen itt csak ezen tudunk programozni – kevés a magyar Python programozó, illetve a kész megoldások hiánya (nincsenek kész alkalmazások, ebbe a környezetbe készült alkalmazáskönyvtárak, stb.). Végül az adatbázis megoldás is bizonyos kötöttségekkel bír, egy lekérdezés futásának az ideje limitált, így például backupot is nehezen lehet készíteni, mert egy teljes lekérdezés túl hosszú ideig tartana, és le lesz lőve, mielőtt bármit kiköpne magából.

Várhatóan lesznek törekvések alternatív hoszting környezet kialakítására szabad forráskódú eszközök használatával, a programozási nyelvek körét is bevallottan bővíteni fogja a Google. Az alkalmazáskönyvtárak, kész kisebb alkalmazások szintén biztosan kialakulnak majd, melyek a praktikus és gyors fejlesztést is lehetővé fogják tenni.

Összefoglalás

Az elkövetkező években a “hagyományos” hoszting mellett várhatóan komoly részt fognak kihasítani az Amazon és Google féle megoldások, de ezek még érezhetően nem “tökéletesek”, és jóval több és rugalmasabb lehetőségünk van, ha még nem döntünk a használatuk mellett. Ezzel együtt akár a részben átállás (ahogy a Twitter teszi), akkor csak a kipróbálásuk/ismerkedés egy olyan feladat, amit nem szabad kihagynia egy webfejlesztőnek, ha haladni szeretne a korral.

MySQL vs. PostgreSQL I.

Published on április 16, 2008 in webadmin és webfejlesztés. 2 Comments

A PostgreSQL-lel való megismerkedés – a MySQL szuper propagandájának köszönhetően :) – kimaradt az életemből, illetve az utóbbi évek alatt nagyon sok ponton fejlődött. Most egy projekt kapcsán elkezdtem ismerkedni vele, az ezirányú tapasztalataimat fogom most és további bejegyzésekben megosztani. A cél nem egy teljes bemutatás, hanem azoknak a hasonlóságoknak, különbözőségeknek a megmutatása, melyekkel találkoztam.

A MacOSX-re történő PostgreSQL telepítés nem túl bonyolult folyamatát már bemutattam másik blogomon, két témára térnék ki most, az egyik a típusok, a másik pedig a dátumkezelés. Értelemszerűen és nyilvánvalóan – mivel mind a két rendszer az SQL szabvány felé próbál minél jobban közelíteni, hatalmas különbségek nincsenek az SQL parancsokat illetően. Megvannak azonban mind a két rendszerben olyan elemek is valósítva, melyek nem szabványosak, és ezek bár hasonlóak, egyáltalán, vagy nem teljesen egyezőek.

Típusok, adatbázis tábla létrehozása

Míg a PostgreSQL alatt részben használhatjuk a MySQL-ben megszokott típus elnevezéseket, az adat típusok elnevezését illetően mind filozófiabeli, mind pedig konkrét elnevezésbeli különbségek adódnak. Az INT, VARCHAR(200), DATE, TIME, TEXT típusok – legalábbis elnevezésükben – megegyeznek (bár a TEXT a MySQL beli LONGTEXT méretű szöveg tárolását teszi lehetővé). Konkrétumokat illetően azonban mindenképpen érdemes a két rendszer ezirányú dokumenticáióját átolvasni: MySQL adattípusok, PostgreSQL adattípusok.

Az AUTO_INCREMENT tulajdonsággal mező a MySQL újítása, PostgreSQL alatt nem áll rendelkezésre (és a szabványban sincs ilyen). Van azonban mind a két rendszerben olyan típus, mely kiváltja, mégpedig a SERIAL. MySQL-ben ez egy alias a ”BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE” típus és tulajdonságlistára, míg PostgreSQL alatt egy szekvenciát hoz létre (mely egy olyan eleme az adatbázisnak, melyből folyamatosan növekvő elemek kérdezhetőek le), és rendeli hozzá az alapvetően INTEGER típusú oszlophoz.

A BLOB típus szintén MySQL sajátosság, PostgreSQL alatt a BYTEA a megfelelője (szabványban nincsen rá külön megfelelő). Míg MySQL-ben direktben hozhatunk létre ENUM (felsorolás) típusú oszlopot, PostgreSQL alatt vagy deklrálni kell egy ENUM típust, vagy pedig a szabványos megkötésekkel lehet szimulálni: mezőnév VARCHAR(255) NOT NULL, CHECK (mezőnév IN (“érték1″, “érték2″, “érték3″…)). A TIMESTAMP típus viselkedése MySQL alatt is függ attól, hogy az adatbázisszerver milyen kompatibilitási módban fut. A jellemző viselkedés mindazonáltal az, hogy ez a mező automatikusan frissítésre kerül az éppen aktuális időponttal ha az adott sort változtatjuk (és ez az első TIMESTAMP típusú oszlop az adott táblában). PostgreSQL esetén DATETIME mezőként viselkedik a TIMESTAMP, azaz semmilyen értékkel nem töltődik ki automatikusan. PostgreSQL alatt hasonló funkcionalitás triggerekkel érhető el.

A fentiek alapján levonható a következtetés, miszerint egyszerű táblákat MySQL-t ismerők is könnyen létrehozhatnak, de komolyabb munkánál mindenképpen áttekintendő a PostgreSQL dokumentációja.

Dátum kezelés

A MySQL kellemes funkciólistával rendelkezik, ha a dátum (és idő) manipulációról van szó. Ez a PostgreSQL-ről is elmondható, nem kell panaszkodnia a dátum manipulációs függvényeit illetően. Az ismerkedés kapcsán két funkciót néztem meg, és ezeket emelném ki, mint egy példát a hasonlóságra, és egy példát a különbözőségre.

MySQL alatt az aktuális időpont a NOW() függvény segítségével kérdezhető le, de ez az érték elérhető a szabványos CURRENT_TIMESTAMP kifejezéssel, vagy a már nem annyira szabványos CURRENT_TIMESTAMP() függvénnyel. PostgreSQL alatt hasonló a helyzet, a NOW() és az SQL szabvány CURRENT_TIMESTAMP használható.

Ha egy adott dátumtól bizonyos távolságra levő dátumra vagyunk kiváncsiak, akkor mind a két adatbáziskezelő alatt az INTERVAL kifejezés jöhet szóba, azonban ezek eltérően paraméterezendőek. MySQL alatt például a SELECT now() + INTERVAL 2 day formátum a használandó, PostgreSQL alatt a SELECT now() + INTERVAL ’2 days’ forma a nyerő. PostgreSQL alatt aposztrófok közé kell tenni az intervallumot leíró kifejezést, és az egyes számot-többes számot illetően megengedőbb (a helytelen 1 days és 2 day is működik), míg MySQL alatt nem lehet aposztróf, és csakis az egyes szám a megengedett.

Összefoglalás

Ismerkedésem kapcsán tervezem további “kalandjaim” megosztását is egyéb területek kapcsán – akármennyire is mind a két rendszer a szabvány SQL-hez próbál meg közelíteni, mint láthatjuk nem kis különbségek vannak. Az mindenesetre elmondható, hogy a PostgreSQL-ben jellemzően több lehetőségünk van, mint a MySQL-ben, még ha nem is mindig lesz könnyebb a helyzetünk ezzel (gondolok itt az ENUM vagy a TIMESTAMP mezőtípusokra).

Intelligens (kereső) robotok

Published on április 12, 2008 in webfejlesztés. 2 Comments

A Google folyamatosan kísérletezik robotjainak fejlesztésével, most is egy ilyen fejlesztésről lehet olvasni blogjukon: Crawling through HTML forms. A legújabb fejlesztésük lényege, hogy feldolgozzák a formokat is, és kitöltik azokat releváns információkkal, majd megnézik milyen választ kapnak. Ha a válasz olyan oldalakat mutat meg nekik, melyeket eddig nem ismertek, akkor ezt a módszert használni fogják az indexelésük során.

Robotok a Doctor Who-ban

A dolog nagyon hasonlít a spam botok működéséhez, fontos tehát hogy lássuk, mi az, amivel a Google-t megállítható, és hogy a hasonlóság mellett mi a különbség. Egyrészt a Google robotok csak a GET kéréseket indító formokat töltik ki, avagy ha jól van felépítve oldalunk, akkor regisztrációs, bejelentkező, kontakt formok nem kerülnek látókörükbe. A másik fontos szempont, hogy a robots.txt-t tiszteletben tartják, így ha valamiért kell, ezúton is kitilthatóak.

A dolog SEO szempontból is fontos lehet. A miner.hu Google felő érkező találatait nézve ugyanis egyáltalán nem jönnek látogatók keresési találati oldalakara – pedig az oldalon kevés ilyen oldal van direktben belinkelve. A Webakadémián nemrégiben átálltunk a “?p=1234″ formájú oldal URL-ről a beszédesekre, még a mai napig is sok GET paraméteres oldal szerepel a Google találati listáján. Ebből én azt a tapasztalatot vonnám le, hogy a Google képes arra is, hogy az oldalainkon levő formok felépítését felhasználva keresési találat jellegű oldalakat felismerjen, és akár ki is zárjon az indexelésből.

CSS Naked Day

Published on április 9, 2008 in webfejlesztés. 0 Comments

Avagy CSS nélküli pucér nap. A kezdeményezés kapcsán egy nap erejéig világszerte tiltják le a weblap tulajdonosok az oldaluk tálalásáért felelős CSS-t, s így tettem ma én is. A cél a modern szemléletű weblapépítés tudatosítása, megmutatása.

Az előbb emlegetett modern elvek szerint a CSS az a réteg a weblap készítés során, mely a megjelenésért felelős, de ha eltávolítjuk, akkor is egy emészthető, átlátható oldalt kell, hogy kapjunk. Olyat, amit szöveges böngészőkkel (lynx, links) is láthatunk, olyat, melyet a nem-látó felhasználók tapasztalhatnak, s olyat, mellyel a (kereső)robotok szembetalálkoznak. Ha jól van felépítve oldalunk HTML része, akkor a látogatónak CSS nélkül is tudnia kell olvasnia a tartalmakat, s navigálnia oldalunkon.