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
- laszlo.spiller blogja
- A hozzászóláshoz be kell jelentkezni
- 1370 megtekintés
Hozzászólások
ennek az irasnak mi a celja? Egy hr-es akar technikai (ki)oktatast tartani? :-)
- A hozzászóláshoz be kell jelentkezni
Ő polihisztró! Mindenben profi.
- A hozzászóláshoz be kell jelentkezni
"Copyright ©2010-2011 ProjectO. Minden jog fenntartva."
Utánközlésre (vagy mire) volt engedélyed? Vagy csak átloptad ide engedély nélkül?
> Nagy letöltés szám például a napi 1.000.000 PI (Page Impression).
Nagy? Pld. 10K request/sec -el számolva, amit egy(azaz 1 db) közönségesnek mondható web szerver is nyújt, ez 100 sec alatt lemegy. De kerüljön 10x annyi időbe, akkor is kb negyed óra kiszolgálni ezt a mennyiséget. Ha 100x annyi időbe kerül, akkor meg ~3 óra, 1/8 nap, 12,5% kihasználtság. Mit csinál a gép a maradék 7/8 (87,5%) időben?
> Egy 20GB-os adatbázis (nem kép, video, vagy audio) elég nagynak mondható.
Nagy? Amíg egy (azaz 1db) PC RAM-jában elfér, én nem mondanám nagynak.
- A hozzászóláshoz be kell jelentkezni
PI != http request/sec.
Szerintem ritka amikor egy komplex oldalnál egy PI-hez csak statikus kiszolgálás kell, az még manapság is a programozó diadala (pl. ESI).
- A hozzászóláshoz be kell jelentkezni
> PI != http request/sec.
Tippelj nyugodtan valami időtartamot a kiszolgálására.
- A hozzászóláshoz be kell jelentkezni
Dinamikus kiszolgálásnál abszolútértékre tippelni se merek. Függ a feladattól, fordítottan arányos a programozó tudásával és belefeccölt idejével. Szóval az 1.000.000 műszakilag lehet sok is, kevés is.
De igazából csak azt akarom mondani, hogy 1 PI lehet akár 300 http req is manapság egy-egy francosabb oldalnál.
- A hozzászóláshoz be kell jelentkezni
[vicc]
...
- Ez biztos matematikus.
- Honnan tudod?
- Sokáig tartott amíg válaszolt; abszolút igaza van; nem megyünk a válasszal semmire.
:-)
[/vicc]
- A hozzászóláshoz be kell jelentkezni
A nagyot az úr abban az értelemben értette, hogy ha valakinek 1 milliós oldalnézettsége van, az már bizony egy komoly weboldalnak számít. Hint: a hvg.hu napi PI-je van 1 millió körül, origo 13 millió körül, amivel a legnézettebb magyar weboldal. Nem arról van szó, hogy technikailag milyen nehéz ennyi oldalletöltést kiszolgálni, hanem arról, hogy ha ennyien kíváncsiak az oldaladra, akkor az már jelentősnek számít.
- A hozzászóláshoz be kell jelentkezni
Erdekes volt olvasni egy laikus szemszogebol a szakmarol. A cikk gondolom 5-6 eves lehet (legalabbis a nagynak szamito DB meret alapjan ugy tunik). A home PC-men van olyan postgres tabla (nem a teljes DB), ami indexekkel egyutt majdnem 21GB, es siman birja. Importnal/exportnal szoszol egy ideig, de nem veszes. (ok, ezt a meretet par index levetelevel, DB szerkezeti atalakitassal lehetne csokkenteni - a sebesseg rovasara, de miutan fejlesztes alatt allo home project, eddig nem erdekelt a merete (az eles felhasznalashoz ugyis konvertalni kell majd).
--
Tudod te, mennyi lóvé fér egy Alstom-kocsi dobozába? :)) - laspalmas, VB
- A hozzászóláshoz be kell jelentkezni