Indítanál egy weboldalt, de nem tudod, hogy ez nagyságrendileg pénzben, időben mit jelent? Gyakori kérdés, hogy a cél, amit az ötletgazda megálmodott ténylegesen mekkora. A kis és nagy projektek között nem csak a látogatók száma tér el, hanem a rendszernek önmagának is meg kell felelnie a kihívásoknak. Ezt a tényt már az első megbeszéléseken tisztázni kell. Nézzük meg, hogy milyen akadályokon kell átugranod, ha egy ilyen fába vágod a fejszédet! Oldalletöltések száma Igen, a fejlesztés oldaláról nézve nem a látogatók száma a releváns, hanem az oldalletöltéseké. A szervert nem érdekli, hogy az adott letöltéseket egy vagy több ember kérelmezi. Nagy letöltés szám például a napi 1.000.000 PI (Page Impression). Fontos ismerni a letöltések eloszlását is, hiszen ebben is jelentős eltérések lehetnek. A KGFB kötések például jellemzően csak egy szűk időintervallumra tehetők (most már ez nem így van, de a példa jól szemlélteti a problémát), tehát az online alkusz rendszereket a teljes hullám kiszolgálására kell tervezni és méretezni. A nagy oldalletöltések kiszolgálására több megoldás is alkalmazható, akár kombinálva is. Lehet cache rendszereket kialakítani, amelyek előre generált elemek segítségével veszik le a terhet a szerverekről. Alkalmazhatunk több szervert (hardware eszközt). A terhelés elosztók több eszközre osztják a forgalmat, a háttérszerverek pedig elvégzik a szükséges műveleteket. A többgépes rendszereken további feladatot jelent a központi felhasználó kezelés. Ha egy felhasználó belép a rendszeredbe, akkor az egyik oldalletöltését az egyik, a másik oldalletöltését viszont lehet, hogy egy másik szerver fogja kiszolgálni. Ilyen esetben is tudni kell a második szervernek, hogy ki az a felhasználó. Adatbázis méret Komoly sebesség problémákat okozhat a túlméretes adatbázis. Egy 20GB-os adatbázis (nem kép, video, vagy audio) elég nagynak mondható. Ezt a méretet okosan kell kezelni, hogy a felhasználást ne akadályozza. Az első, amit alkalmazni kell ilyen esetben az a jól beállított indexek. Ezek a keresést és az elérést is egyaránt gyorsítják. Az indexelés a keresést meggyorsítja ugyan, de a beírást lassítja. Ennek megfelelően kell a megfelelő kompromisszumos megoldást megtalálni. Az adatbázis lekérdezések optimalizálásával tovább gyorsíthatsz a rendszereden. Esetleg ha még tovább kell menni, akkor az adatbázist több szerverre kell elosztani. Tárhely méret Az óriási tárhelyet igénylő rendszerek, amelyek alatt a nagymennyiségű audio és video anyagot tároló rendszerekre gondolok, szintén komoly akadályokat gördítenek a projektgazdák elé. Itt nem maga a tárhely lesz a probléma, hanem a sávszélesség. Az anyagok stream-elésének nagy a sávszélesség igénye. Amennyiben a sávszélességi lehetőségeinket kimerítettük, akkor alkalmazhatunk CDN (Content Delivery Network) szolgáltatást. Ezek a rendszerek az adatokat több szerveren – amelyek különböző helyeken vannak – tárolják (cache-lik), és az oldalletöltéseket a helyileg legnagyobb sávszélességgel elérhető szerverről (cache állományból) szolgálják ki. Ez egy nélkülözhetetlen megoldás, ha nemzetközi szinten szeretnél audio/video anyagokat szolgáltatni. Nagy méret például az 1TB ilyen típusú adat. Adatbázis intenzív oldalak Korábban szó volt az oldalletöltések számáról. Most azt a kihívást boncolgatjuk, amikor egy oldalt töltesz be, de ehhez az oldalhoz nagymennyiségű adatbázis művelet kapcsolódik. Ez lehet olvasás intenzív, például 10.000 elemet szeretnél megjeleníteni, sok lekérdezéssel kell az oldalt összeállítani vagy az archive feed-ek, ahol sok helyről kell adatokat összeszedni. Lehet írás intenzív is, amikor például minden oldalletöltésnél nagy mennyiségű adatbázisírás van. Például a 1.000 különböző termék megvásárlása webshop-ban. Az olvasás intenzív kihívásokra a lekérdezések cache-lése jelenthet megoldást, írás intenzív esetben pedig háttérfolyamatok kiépítését javasolnám. Erőforrás intenzív, időigényes folyamatok Erőforrás intenzív folyamat például a hírlevél kiküldés, vagy audio és video konvertálás. Ide tartoznak a telepítési és adatimportálási feladatok is. Ezekhez mindenképpen háttérfolyamatok és/vagy jobqueue-k alkalmazása a legjobb gyakorlat. Oldallátogató minősége Itt nem a kedvességére gondolok, hanem arra, hogy milyen mértékben veszíthető el a felhasználó. Az elveszíthető felhasználó az, aki új érdeklődő, a bizalma feléd még nem elég erős. Aki például az online szolgáltatásodat először próbálja ki, az nagymértékben elveszíthető, könnyen távozhat, mert ha lassú a kiszolgálása, akkor elhagyja az oldaladat és nem lesz a vásárlód. Aki viszont a szerkesztőségi rendszeredben video-kat tölt fel, az nem elveszíthető, hiszen ez a mindennapi feladata. Vagy kevésbé elveszíthető az, aki korábban már felhasználója volt a rendszerednek. Az elveszíthető felhasználók felületeire sokkal nagyobb figyelmet és energiát kell fordítani a projekt tervezése során. Itt a cache-lés mellet a minimalizált adatforgalom lehet jó megoldás, a minőségi HTML-kód előállítása illetve a kódok minify-olása segítségével. Alkalmazhatók optikai elemek is, például előtöltők, de ezek csak a gyorsabb letöltés érzetét adják. Külső tartalmak Nem elhanyagolható pont a harmadik fél. Ilyen esetben az oldal összeállításához nemcsak a saját adatbázisunk és rendszerünk szükséges, hanem egy harmadik féltől (is) töltünk adatokat. Ebben az esetben fel kell készülni arra, hogy mi tegyen a rendszerünk, ha a harmadik fél lassú vagy nem elérhető. Ha nem ügyelsz erre, akkor a Te oldalad is belassul, vagy akár le sem jön. Erre egy jó megoldás lehet egy háttérfolyamat, ami automatikusan cache-li a harmadik fél által prezentált adatokat. Az itt leírt kihívások a nagy projektek jellemzői, amelyekben ezekből több is megjelenik. A nagy projektek problémája az, hogy a felsorolt akadályok egymással szorzódnak, tehát ha a projektedre nagymennyiségű oldalletöltéssel kalkulálsz, ami ráadásul adatbázis intenzív is, máris komoly feladat előtt állsz. Tanulság A kihívásokat Neked és minden projektrészvevőnek ismernie kell már a kezdeteknél, mert minden esetben van alkalmas megoldás. A megfelelő architekturális tervezés és a megfelelő, csak szükséges eszközök összeválogatásával költséghatékony megoldások készíthetők. Így elkerülhetők a figyelmen kívül hagyott problémák által generált (akár óriási) rejtett költségek. Forrás: ProjectO.hu