Mit is jelent egy webáruház sebessége vagy teljesítménye? Ezek általában indikátorokkal objektíven mérhető, illetve szubjektív felhasználói érzetre alapuló jellemzők. A teljesítmény vagy sebesség a webáruház általános működése során tapasztalt körülmények (úgymint betöltődési idő, felhasználói oldalról érzékelt válaszidők, terhelhetőség), amelyek meghatározzák a felhasználói élményt és az üzleti folyamatok kielégítését.
Mitől függ webáruházunk sebessége?
Első körben nézzük meg, milyen körülmények befolyásolják Magento webáruházunk teljesítményét. Ezeket két csoportra oszthatjuk:
1) A Rendszert alkotó komponensek tekintetében:
- A webáruházunk sebességét értelemszerűen meghatározza portálmotorként funkcionáló gyári Magento alapszoftver aktuális teljesítménye, amely verziók függvényében kis mértékben eltérő lehet.
- Természetesen befolyásolja a sebességet a webáruházat futtató szerveroldali szoftveres környezetek (pl. PHP, MySQL) frissessége, verziója, konfigurációs állapota, szerveroldali cache-elési eljárások, illetve maguk a hardveres jellemzők is (mint például: processzor teljesítmény, memória, skálázottsák, klaszterezési állapot, hálózati sávszélesség, stb.)
- Fontos sebességet befolyásoló tényező a webáruházban jelen lévő fejlesztések volumene, a modulok száma és minősége. A Magento portálmotorhoz illesztett egyedi fejlesztésű vagy külső modulokon túl a frontend sablon minősége és komplexitásának is befolyással van a teljesítményre.
- Amennyiben webáruházunk külső szoftverekkel (jellemzően vállalatirányítási rendszerekkel) integrálódik, ezen interfészek is többlet terhelést jelenthetnek a webshopunk számára. A rendszert alkotó interfészek és rendszerintegrációs megoldások befolyással vannak a teljesítményre.
2) A Rendszert érő futtatási és használati körülmények tekintetében:
Nyilvánvalóan a felhasználók által érzékelt sebességet erősen befolyásolja a webáruházat érő terhelés és látogatói forgalom (különös tekintettel a kampányszerű forgalmi kiugrásokra). Más lesz a webshopunk sebessége egy Black Friday kampány alatt, amikor akár több ezren tartózkodnak a checkout folyamatban mint mondjuk egy nyugalmas nyári reggelen.
Befolyásolja a teljesítményt a webáruház admin felületét használó adminisztrátorok száma és az adminisztráció intenzitása. Minél több adatbázisba író művelet zajlik, annál jobban terheljük a rendelkezésre álló kapacitásokat. (Ilyen tekintetben a Magento webáruház és vállalatirányítási rendszerek, külső szoftverek közötti integrációs folyamatokat is „heavy user” adminisztrátoroknak tekinthetjük, hiszen ezek webservice-alapú folyamatok állandóan importálnak, exportálnak adatokat, indexeléseket futtatnak, cache-t üríthetnek, stb.)
A Magento teljesítményét kifejezetten befolyásolják még az alábbi használati tényezők is:
- A webáruházban jelenlévő termékek, kategóriák és termékjellemzők mennyisége
- A webáruházat érintő importálási eljárások volumene, gyakorisága
- A webáruházba feltöltött multimédia és képi tartalmak mérete, optimalizáltsága
- A futtatott árszabályok, kuponok és egyéb katalógus indexelést vagy lekérdezéseket indító műveletek mennyisége
- A webáruházban alkalmazott nyelvi és boltnézetek mennyisége
Jól látható tehát, hogy Magento webáruházunk teljesítménye több tényező függvénye. Erősen befolyásolja a szerver infrastruktúra, az alkalmazott fejlesztési eljárások, a funkcionális komplexitás de éppúgy kihatással van rá a webshop használatának módja, körülményei.
Gyakran előforduló kérdés, hogy a webshop kielégítő teljesítményének biztosítása vajon kinek a felelősségi köre. Fejlesztői feladat, szerver üzemeltetői kérdéskör, esetleg adminisztrációs használathoz köthető? Nos, a korrekt válasz erre az, hogy ha webshopunk teljesítményét javítani szeretnénk, akkor mindhárom területtel egyenlő súllyal foglalkoznunk kell.
Szerver infrastruktúra követelmények
Kezdjük a legfontosabbal: a Magento 1-es és 2-es verziója is robosztus szoftver, így „vasigényes”, erős szerver hátteret igényel. Amennyiben nem tesszük alá a szükséges infrastruktúrát, akkor bizony komoly sebesség és teljesítmény problémáink lesznek. Ebben a tekintetben lényegesen nagyobb erőforrásra van szüksége, mint például egy WordPress vagy Drupal alapú portálnak. A klasszikus értelemben vett shared hosting tárhelyeket a Magento esetében felejtsük el, legalább egy VPS-re, ideális esetben dedikált szerverre, nagy terhelés és komplex funkcionalitás mellett pedig klaszterezett szerverekre vagy egy kellően erős cloud alapú kiszolgálásra lesz szükségünk. Amennyiben a webshop ERP-vel integrálva üzemel, célszerű az integrációt megvalósító middleware szoftvert külön szerveren üzemeltetni.
Mennyiben kerül mindez? Nos, az infrastruktúra költségek széles spektrumon mozognak. Kisebb terhelés vagy egyszerűbb funkcionalitás mellett egy VPS is megfelelő lehet, ez általában havi 20-30 ezer forintos kiadást jelent. Nagy (többezres) cikkszámú és viszonylag intenzív értékesítési frekvenciájú Magento webáruházhoz egy dedikált szerver vagy egy erősebb cloud környezet ajánlott, ami 40-60 ezer forintos havi kiadásra rúg. Egy több képből álló klaszter (különálló frontend szerverek, adatbázis szerver, load balancer) esetén már potenciálisan többszázezer forintos havi költséggel kalkulálhatunk.
Sokszor felmerül a kérdés, hogy webáruház tulajdonosként érdemes-e saját szerverre beruháznunk? Erre a válasz egyértelműen az, hogy nem. Saját szerverrel jelentősen beszorítjuk későbbi mozgásterünket, korlátozottak a bővítési lehetőségeink, megnövekvő igények esetén nem is tudunk olyan rugalmasan konfigurációt váltani, ráadásul ilyenkor a szerver üzemeltetésének know-how-ját is be kell szereznünk. Cloud alapú megoldások esetén ráadásul a megnövekedett kapacitás szükségletet akár nagyon rövid időre (pl. kampányokhoz igazítva akár csak pár órára) azonnal sokszorozni tudjuk.
(Disclaimer: az Oander nem foglalkozik szerver üzemeltetéssel, semmilyen hasznunk nem származik abból, hogy ügyfeleink hol üzemeltetik a webáruházaikat. Így ezt a tanácsunkat nem anyagi haszonszerzés motiválja, hanem a gyakorlati tapasztalat.)
Fejlesztés oldali gyorsítási eljárások
A következőkben nézzünk meg néhány olyan fejlesztésoldali eljárást, amivel a megnövekedett igényeket elő tudjuk segíteni. Optimalizálásnak azokat fejlesztési megoldásokat vagy a futtatási környezetet érintő eljárásokat nevezzük, amely a webáruház sebességének és teljesítményének javítását szolgálják. Az alábbiakban ismertetünk párat, amelyeket javasolni szoktunk, ha Magento webáruházunk teljesítménye javításra szorul.
Az alábbi lista messze nem teljes, sokkal inkább a tipikusan javasolt, legnagyobb eredményt hozó első lépéseket ismerteti. Fontos, hogy az alábbiak jellemzően továbbfejlesztési feladatok, a Magento alap működésének nem részei.
- Block cache: Jellemzően a kategória oldal gyorsítótárazásának átalakítását értjük ez alatt. A Magento alapértelmezetten minden egyes kategória oldalt egy az egyben tárol le, viszont a gyakori termékfrissülések miatt ezek a gyorsítótár mentések igen hamar elavulhatnak. Ilyenkor a Magento-nak újra és újra be kell cachelnie őket, ami növeli annak az esélyét, hogy a felhasználók nem gyorsítótárból kiszolgálta tartalomra jutnak, és ez folyamatos terhelést jelent a webáruházban. A block cache metódus ennek kiküszöbölésére ad egy lehetséges megoldást. Segítségével nem a teljes kategória oldalt, hanem külön-külön a termékeket, és azok frontenden megjelenő adatait gyorsítótárazzuk, így a termék frissítést követően csak a változott termékek kártyáit kell újra betöltenünk a cachebe. Magyarán egyetlen termék árának vagy készlet információjának frissülése nem eredményezi egy teljes kategóriaoldal gyorsítótárának elévülését. A block cahe bevezetése csak nagyon intenzív termékfrissülés mellett indokolt, mert használatával drasztikusan megnő a törlendő gyorsítótárazott adatcsomagok darabszáma. Ezért a gyorsítótárazási rendszer által használt alap törlési metódusokat is tovább kell hozzá fejleszteni, hogy a törlési folyamatokat csoportosítva csökkentettük a kérések számát.
- Lazy load: Főleg a címlap, hosszabb oldaltípusok és a kategória oldalak gyorsítása érdekében szoktuk javasolni ezt a módszert. Lényege, hogy nem az oldal megnyitásakor töltődik le minden termékkép és UI komponens, csak közvetlenül az előtt, amikor a felhasználónak megjelenne (vagyis az oldal görgetése közben.) Ezzel a felhasználó számára sokkal gyorsabbá tudjuk tenni az első, teljesen lerenderelt és betöltött oldalállapotot. Ez a megoldás nem az oldalak tényleges betöltésének idejét gyorsítja, hanem a felhasználó által észlelt betöltődési időt, ám azt igen jelentősen.
- Cache Warmup: Ennek a fejlesztésnek a célja előre definiált függvények alapján az ajax-os cache részek betöltése, adott esetben a termék oldalra is alkalmazható. Ennek az az értelme, hogy cache ürítés után a cache-t automatikusan megtöltjük tartalommal, hogy az első felhasználók akik éppen ürített cache tartalomra érkeznének már cachelt állapotot lássanak. Ezzel csökkentjük a cacheletlen tartalmakkal találkozó userek számát, nehézsége, hogy a cahce ürítés folyamatát bonyolítja.
- Fájlok csoportosítása a visszatérő látogatóknak: Egy lehetséges sebesség növelési megoldás, hogy az oldalak megjelenéséhez és felhasználói oldali működéséhez szükséges fájlokat összefűzzük csoportos fájlokba, így a böngészőnek kevesebb fájlt kell feldolgoznia a megjelenítés során. Az így készült fájlok nevéhez mindig hozzátesszük a generálás időpontját, így a felhasználók böngészője automatikusan tudni fogja, hogy szükséges-e letölteni az éppen fent lévő verziót, vagy megfelelő-e az előző. Ezzel tehát a visszatérő látogatók számára gyorsítjuk az oldalt.
- Modultisztítás: Huzamosabb ideje működő és folyamatosan fejlesztett Magento webáruházak tipikus jellemzője, hogy rengeteg modult tartalmaznak – olyanokat is, amelyekre nem lenne már szükség. Ezek – még ha nincsenek is használatban – a háttérben foglalhatják az erőforrásokat. Érdemes legalább évente alaposan átnéznünk webáruházunk moduljait, és amelyekre már nincsen szükségünk, azokat távolítsuk el. Nem elegendő a modulokat lekapcsolni, adatbázis szinten is el kell távolítani a maradványaikat.
- Nagy méretű log táblák ürítése: Röviden arról van szó, hogy a Magento-ban a debuggolás és a folyamatok visszakereshetősége miatt minden (jól megírt) modul log-okat ír magából, amiket adatbázisban tárolunk. Ezek hajlamosak igen jelentős méretre duzzadni: célszerű időről időre archiválni és üríteni ezeket, így nemcsak tárhelyet spórolunk de tehermentesítjük az adatbázist is.
