A Drupal üzemeltetése magában sem könnyű feladat. Fokozottan erőforráspazarló rendszer, alapjáraton is sok memóriát eszik, a rengeteg lekérdezést pedig a rengeteg optimalizálás ellenére is megérzi a rendszer. A különböző forrásokból származó (akár beta verziós) plusz modulok feltelepítésével pedig tovább romlik a helyzet. Több különböző weboldal közös tárhelyen történő üzemeltetésekor pedig egyszerre akár 100 weboldal is egy egybefüggő szerverparkon kerül kiszolgálásra. Ezek között - népszerűsége miatt - a Drupal bizony szép számban előfordulhat.

Webadmin névre keresztelt, saját fejlesztésű adminisztrációs felületünk, pénzügyi rendszerünk, valamint hivatalos weboldalunk is Drupal alapokon nyugszik. Ezeknek és a különböző ügyfelek által üzemeltetett hasonló oldalaknak hála az elmúlt évek során egyre több tapasztalatot gyűjtöttünk ezek üzemeltetésében is. Az alábbiakban röviden összefoglaljuk a sebességnövelés főbb lehetőségeit. Ezek a technikák éppúgy hasznosak lehetnek kisebb méretű weboldalak esetén, mint összetett adatbázissal rendelkező multi-site rendszereknél. A motor többrétegűsége és az azt kiszolgáló rendszerek sokfélesége miatt azonban az optimalizálás szerteágazó feladat lehet. Ha valakinek ez a célja, az egyes témák mindegyikében egyenként el lehet merülni és igény esetén egy-egy területen komolyabb finomhangolási módszereket bevetni.

Biztos, ami biztos

Legyen kikapcsolva az összes olyan modul, ami az oldal működéséhez nem szükséges feltétlenül. Ebbe beletartoznak a fejlesztést segítő kiegészítők is, mint a Toolbar és az Update manager. A Beállítások->Teljesítmény menüpont alatt mindenképp érdemes bekapcsolni a cachelést anonymous felhasználók részére engedélyező funkciót. Ugyanitt állítható be a gyorstárak minimum is maximum élettartama is. Ennek beállításakor azt érdemes figyelembe venni, hogy milyen gyakran frissül az oldalak tartalma. Ellenőrizd, hogy a képek nem túl nagy méretűek, a beépülő Javascript modulokból (jQuery és társai) pedig mindenhol a minimalizált verziót használod, hogy ezzel is kíméld az adatforgalomtól a szervert és a klienseket egyaránt.

A Cachelés a barátod

A teljesítményt fokozó kiegészítők közül érdemes feltenni az Alternative PHP Cache, a Boost és az Aggregate cache modulokat. Ezek használatával legalább 1 nagyságrendnyi gyorsulást értünk el az oldalaknál: A valós időben generált dinamikus tartalmaink kb. 5-10x, a többnyire statikus tartalommal rendelkező oldalaink 15-20x gyorsabb idő alatt töltődnek be. Ezt főleg a Boost modul használatának köszönhetjük. Az "aggregate cache" funkció főleg akkor segít, ha a böngészőnek sok kliensoldali tartalom letöltésével kell megküzdenie. Ilyenkor a CSS és JS fileok összetömörítve, egy-egy pakkban utaznak a böngészőig és így kevesebb sávszélességet foglalnak.

Ami a háttérben van

Nem mindegy, hogy milyen teljesítményű az oldal mögött az a rendszer, ahonnan az adatok valójában nyerjük. Felülről lefele ásva először érdemes utánamenni, nincsenek-e lassú, egyedi SQL lekérdezések a kódban, amik akadályozzák az oldalak gyors betöltődését. Ehhez a legelterjedtebb (mára ipari standarddá vált) MySQL adatbáziskezelő esetében a mysql_slow_query.log és az EXPLAIN utasítás adhat a legkönnyebben segítséget. Érdemes megfontolni, hogy MyISAM vagy InnoDB motort használjuk-e az adatok tárolására. Mindegyiknek vannak előnyei és hátrányai egyaránt. Aki pedig valamilyen másmilyen (Postgres, vagy valamilyen NoSQL) adatbáziskezelőt használ, remélhetőleg tudja, miért teszi azt. Legvégül, a háttértár teljesítménye is döntő tényező lehet. Alapvetés, hogy a kiszolgált oldalt tároló filerendszer, a működéséhez szükséges adatbázis és a futás során készülő log fileok mind-mind külön helyen legyenek tárolva. Ha ezeket a területeket egy időben egy helyről írja és olvassa a rendszer, az elég nagy overheader generálhat. Válasszuk ezeket külön, ha még nem tettük. Lényeges adatok tárolására valamilyen RAID megoldás használata manapság már magától értetődő. A legjobban skálázható megoldás azonban valamilyen elosztott rendszer használata. Erről a témáról és felhőszolgáltatásunkról a jövőben is rendszeresen jelentetünk meg írásokat itt, a blogunkon. Reméljük használható segítséget tudtunk nyújtani. Örömmel vesszük bárki tapasztalatait a témában!

A legtöbb ember tart attól, hogy oldala egyszer csak hirtelenül elérhetetlenné válik. Többszörösen túlbiztosított rendszerek esetén is előfordulhatnak hibák, bizonyos tényezők mindig fennállnak. A 100%-os rendelkezésre állás fizikailag lehetetlen fogalom. Fontos tudni, mit tegyünk, hogy megelőzzük a bajt, vagy ha már bekövetkezett, hogyan hárítsuk el minél gyorsabban a hibát?

A leállás oka

• Tervezett leállás: Bekövetkezhet hardverbővítés vagy szoftverfrissítés miatt. Az operációs rendszer, illetve egyes kiszolgáló szoftverek frissítésekor néhány esetben újraindítás szükséges. Ez is szolgáltatáskimaradáshoz vezet.
• Egy adott komponens hibája: Valamilyen meghibásodott hardveregység, programhibák, vírusok, a fájlrendszer megsérülése és adatvesztés.
• Üzemeltetői vagy felhasználói hiba: Szándékosan vagy akaratlanul törlődött fájlok, képzetlen operátori tevékenység, internetes betörés, rosszindulatú felhasználók által okozott probléma.
• Katasztrófaesemény: Rendkívüli áramkimaradás, tűzeset, földrengés, árvíz, stb. Szerencsére ez utóbbiak hazánkban viszonylag ritkán fordulnak elő.

A felhasználók számára a legtöbb esetben nem tudatosul a leállás valódi oka, csak azt veszik észre, hogy az elérni kívánt oldal egyáltalán nem, vagy csak lassan töltődik be, esetleg más tartalom jelenik meg rajta. A szolgáltatás kimaradása kihatással van az üzletre. Az, hogy egy időre az oldal működése szünetel ronthatja a felhasználók általános elégedettségét is. Ha sűrűn fordulnak elő kimaradások, a megrendelők egy idő után elpártolnak. Ha akkor áll le a szolgáltatás, amikor éppen egy befektető bóklászik az oldalon, annak különösen rossz vége lehet. Ha a rendszer működésében állandó kimaradások jelentkeznek akár egész napokra, azt a keresőoptimalizálás is megszenvedi. A sűrű kimaradást és elérhetetlenséget a különböző keresőmotorok súlyosan büntetik.

Hogyan előzhető meg a baj?

• Mindig legyen kéznél mentés - A rendszeres biztonsági mentés mellett érdemes minden nagyobb változtatás előtt is eltárolni az adatokat arra az esetre, ha valami balul sülne el.
• Ellenőrizd, hogy a domain előfizetésed rendben van-e - Nagyon sok panasz érkezik a szolgáltatókhoz (hozzánk is) amiatt, hogy a tulajdonosok, elfelejtik meghosszabbítani előfizetésüket, mielőtt az lejárna. A legtöbb cég figyelmeztető e-mailt küld a lejárat előtt pár héttel, azonban a kapcsolattartói e-mail cím az évek alatt megváltozhat, így bizony előfordul, hogy a címzett nem kapja ezt meg. Ha a szolgáltatódnál lehetőség van rá, állíts be automatikus meghosszabbítást.
• Fizess elő valamilyen monitorozó szolgáltatásra - Ezek folyamatosan figyelik oldalad működését és leállás esetén SMS-ben vagy emailen keresztül értesítenek arról. Több ilyen célra létrehozott publikus szolgáltatás is létezik hazánkban és nemzetközileg egyaránt - akár ingyenesen is.
• Használj egyedi hibaüzeneteket - Az oldal szünetelése alatt is sokat dob a megjelenésen az egyedi hibaüzenet. A keresőrobotok pedig jobban szeretik, az 501-es (Service Unavailable) hibakódot, mint a 404-et (A kért lap nem található). Keresd fel az oldalad üzemeltetőjét ez ügyben.

Mit tegyünk, ha megtörtént a baj?

1. Ellenőrizd, hogy tényleg mindenki számára megszűnt-e az elérés és nem csak a te internetszolgáltatásoddal van a baj. Először mindig kérdezz meg valakit, hogy neki se jön-e be az oldal.
2. Próbáld meghatározni meg az okot. Ha járatos vagy a témában, elkezdheted kideríteni, hogy mi a probléma forrása. Elromlott hardware? Programozási hiba? Fennakadás a DNS működésében?
3. Vedd fel a kapcsolatot a szolgáltatóddal. Jelezd a hibát és kérj segítséget. Ha ők nem tudnak segíteni, keress valahonnan egy másik hozzáértőt.
4. Jelezd a felhasználóknak, hogy ha hosszabb leállás történt. Ne hagyd őket kétségek közt. Akár megüzenheted Facebookon vagy twitteren keresztül is. Az ilyen gesztusokat nagyra szokták értékelni. Tervezett leállás esetén előre értesítheted őket emailen keresztül is.
5. Maradj folyamatos kapcsolatban azzal, aki elkezdte a hiba elhárítását. Nyújt neki segítséget bármilyen kérdésben és várj türelemmel.

A bejegyzés a KissMetrics infografikája alapján készült.

A szolgáltatóváltás olyan dolog, ami senkinek sem hiányzik, de néha bárkivel előfordulhat, hogy nincs más megoldás. Az új tárhelyszolgáltató kiválasztása után, ha már minden dolog rendelkezésre áll, át kell mozgatni az eddigi oldal tartalmát (a fájlokat és az adatbázist, ha van) az új helyre, majd egy ellenőrzés után a domainhez tartozó DNS szerverekben frissíteni kell az oldalt kiszolgáló szerver IP címét az új tárhely címére. Ha mindent jól csináltunk, a weboldal folyamatos működése biztosított lesz.

1. Miután az előfizetést megkötötted, a szükséges beállítások elvégezése után az új szolgáltatód kell, hogy küldjön egy belépési adatokat tartalmazó levelet a számodra. A levélben biztosan szerepelnek az FTP eléréshez szükséges adatok, illetve a webkiszolgáló IP címe, amin keresztül az ott hosztolt oldalak a böngészőből elérhetőek. Erre a gépre kell majd irányítani a DNS rekordokat, ha az oldal teljes tartalma rendben átkerült az új helyre.

2. Egy FTP kliens segítségével lépj be az oldalt eddig tároló szerverre és töltsd le az összes hozzá tartozó fájlt. Vigyázz, hogy a könyvtárstruktúra érintetlen maradjon! Amíg a DNS rekordok ide mutatnak, ne töröld a fájlokat a régi helyről, hiszen elérhetetlenné válna az oldalad. Ha adatbázist is használsz az adatok tárolására - pl. blogot vagy portálrendszert üzemeltetsz - akkor szükség van ezeknek az átmozgatására is. A legtöbb helyen az exportálás könnyen elvégezhető, mert a szolgáltató támogat (egyes esetekben előre telepít) valamilyen adatbázis-adminisztrációt egyszerűbbé tevő célszoftvert, ilyen pl. a PHPMyAdmin.

3. FTP-zz be az új szolgáltató szerverére is. A legtöbb esetben a kezdő könyvtár helyett valamelyik alkönyvtár beljesébe kell másolni a fájlokat, hogy azok kívülről elérhetőek legyenek. Ennek a cégtől kapott tájékoztató levélben szerepelnie kell, általában public_html vagy www. Ugyanígy az esetleges adatbázist is fel kell tölteni a mentett tartalommal, így valamilyen módon importálni kell bele az adatokat tartalmazó fájlt.

4. Nyisd meg a böngésződ és az új szerver IP címét beírva, ellenőrizd, hogy az oldalad működik-e. Ha egy IP cím alatt több weboldal is üzemel ugyanazon a kiszolgálón, akkor ideiglenesen a domainhez az új IP-t a hosts fájlba felvéve a teljes hosztnév alapján lekérhető válik az oldal az új helyről - addig is, amíg a domainhez tartozó bejegyzések még a régi szerverre mutatnak.

5. Ha mindent rendben találtál, akkor kérvényezheted a domainedet üzemeltető szolgáltatónál, hogy módosítsa a DNS bejegyzésben tárolt IP címeket az új kiszolgáló címére. Az új DNS paraméterek teljes életbelépéséig technológiai okok miatt beállításoktól függően néha eltelhet 24-48 óra is (a rezolver szerverek cache-ének ki kell ürülnie), néha ennyi ideig kell várni, hogy a domain név a világon mindenki számára az új helyre mutasson - erre a szolgáltatók általában külön felhívják a figyelmet.