A WooCommerce méret kérdései: egyáltalán nekünk való?

Régóta tervezek írni a WooCommerce méretezési kérdésekről, és igazából gondban vagyok azzal kapcsolatban, hogy ezt a szerteágazó és egyben sokrétű témát hogyan is lehetne a legjobban feldolgozni úgy, hogy érthető legyen nem technikai beállítottságú ügyfeleknek és döntéshozóknak, de sikerüljön újat és tartalmasat mondani, a hozzáértő kollégáknak is. Nehéz vállalás, de fogjunk neki!

Az alapkérdésünk ugye az, hogy biztosan jó-e a WooCommerce arra a projektre, amit kitaláltunk?

Ez az egyszerű kérdés számos más kérdést is felvet, ezért most ezeket fogjuk sorba venni, témánként.

Elöljáróban annyit azért érdemes tudni, hogy szinte minden megoldható WooCommerce-ben, de a legtöbb felmerülő probléma megoldható hozzáértő fejlesztéssel és a megfelelő kiszolgáló környezettel.

Hány termékünk, termékvariációnk lesz?

Miért lényeges ez a kérdés? Mert, az adatbázis bizonyos részeiben (postmeta táblák) tárolódik az adatok jelentős része, a tábla mérete a termékek és a termék variációk számának növekedésével együtt iszonyatosan meg tud nőni. Egy termékhez átlagosan 30-50 sor képződik ezekben, a meta adatokat tároló táblában. Ez 50.000 termék esetében fel tud hízni 1.500.000 sorra önmagában, ezt általában az úgy nevezett osztott tárhelyes szolgáltatók már nem szokták elbírni és tanácsolják, hogy az oldal költözzön át saját VPS-re.

Természetesen, kevesen szeretnének ilyen sok terméket az áruházukban, ezért nem mindenkinek kell, hogy ez a szempont fontos legyen.

A sok termék a fentiek mellett több adatbázis tábla (postmeta és termrelationship) növekedését is magával hozza, de az igazán idegesítő a meta tábla növekedése, mert arra lett tervezve, hogy minél flexibilisebb legyen és bármilyen adatot tárolni lehessen benne, amit a WooCommerce ki is használ.

De, az adatokat tartalmazó mező (meta_value) nincs indexelve és ez így is van jól. Egyrészt, mert vegyes adatok lehetnek benne (bináris, szöveg, szám, json), ezért az index hatékonysága egyébként sem lenne jó, tehát adattárolásra kiváló, de ezekben keresni nagyon erőforrás igényes lenne; erre keresünk megoldást a következő részben.

Hogyan akarunk keresni a termékek között?

Keresni mindenki szeretne a termékek között, csak nem mindegy, hogy hogyan tehetik ezt!

Néhány termék esetén a keresés megint nem jelent gondot, de ha visszatérünk az előző példához és jelentős mennyiségű termékünk van, akkor végtelen adatbázis kereséseink lehetnek, főleg, ha szeretnénk, mondjuk gyártó és szín szerint szűrni, esetleg a feltöltési idő alapján rendezni azokat a termékeket, amelyek a Csip-csup kategóriába tartoznak és akciósak.

Technikai oldalról ez egy egészen combos adatbázis lekérdezéshez vezethet, ami többször is át fog nyargalni a több mint fél milliós adattáblánkon (és minden valószínűség szerint ideiglenes táblát fog használni SQL kiszolgáló eközben, ami nagy terhelés alatt egyenlő az öngyilkossággal). A sebesség növekedés nem csak, hogy lassabb találati oldalt fog eredményezni, de a teljes rendszert is lassítja majd, amivel nőni fog a visszafordulási arányunk, mert kilép az érdeklődő, és elmegy egy másik webshopoz, amiben gyorsan tud keresni.

Nagyjából 3-4 másodperc az elfogadható várakozási idő, utána minden egyes másodperccel 5-10%-al nő a lepattanó látogatók száma.

A weboldalak talán egyik legelhanyagoltabb területe a keresés.

Természetesen létezik áthidaló megoldás erre is, például le lehet cserélni az kereső funkciót Elastic Search, vagy Solr alapúra, viszont ez egy nagyobb átalakítás, ami lényegesen bonyolultabb, mint egy bővítmény telepítése, viszont egy méret felett erre, vagy egy ehhez hasonló megoldásra biztosan szükség lesz.

Ezek a megoldások úgy működnek, hogy szükség van a használatukhoz egy külső szolgáltatásra, ami json/xml formában várja az adatokat, és mindkét megoldás kimondottan arra való, hogy gyorsan adjon vissza találatokat. A keresési lekérdezések kerülnek átirányításra ezekhez a szolgáltatásokhoz, így bár a lekérdezés a WordPresshez eljut, de a keresés lényege nem MySQL-ben kerül lefuttatásra, hanem ezek a bővítmények megpróbálják imitálni a natív keresési eredmények kimenetét.

Mennyi megrendelésre számítunk?

Az üzleti kérdéseken kívül, technikailag is fontos, hogy mennyi megrendelés lesz a rendszerben. A fenti két kérdés alapvetően a termékek számáról szólt, ez a szempont viszont kis termékszámmal de sok megrendelést teljesítő virtuális bevásárlóterek esetén is probléma lehet. A fenti már említett dolgok mellett a sok korábbi megrendelés az adminisztrációs rész lassítását is magával hozhatja, és ezt nem oldja meg az Elastic Search, sem a Solr.

MariaDB Galera Cluster

De, ha ilyen problémával találkozunk, akkor kell elgondolkodni más fajta tárhelyen, mondjuk dedikált gépen, vagy akár több gépes környezeten. Ha ezek már mind megtörténtek, akkor következhetnek olyan megoldások, mint több adatbázis szerver használata, kezdetben egy master-slave replikációban, vagy egyből egy master-master replikálásban, esetleg egy három gépes multi-master környezetben. Ez a megoldás MariaDB adatbázis szervereken mintegy három éve – az 10.1-es kiadás óta – elérhető, és Galera Clusternek hívják.

A fenti műveletek elvégzése pénz és hozzáértés kérdése is, de nem űrtudomány, mégis megkívánja a szakértelmet.

Egy egyszerűbb alternatíva lehet valamelyik felhő szolgáltatásba költöztetni az oldalt. Önmagában a költözés nem oldja meg a teljesítmény problémákat, de kezelhetővé teszi, az által, hogy annyi teljesítményt tudunk az oldal alá tenni, amennyit csak a PayPal accountunk elbír. Google Cloudban például néhány kattintással létre lehet hozni egy replikált adatbázis megoldást.

Milyen sablont használunk?

A legtöbb induló webáruháznak tökéletesen megfelelnek az olcsó, akár ingyenes sablonok, de ahogy növekszik az oldalunk látogatottsága, úgy kezdünk el gondolkodni azon, hogy mitől is lehetne az oldalunk gyorsabb, és sokszor a sablon a megoldás. Hogy tényleg a sablonnal van-e gond, azt PHP profiling eszközökkel tudjuk kideríteni. Mi erre a New Relic megoldását használjuk, ami jóval többet tud egyszerű profilingnál, de erre is kiváló.

New Relic

Ugyanis, az általános célú, vagy a sok mindenre jó sablonok (Avada, Divi, Elementor, stb.) az esetek nagy részében olyan funkciókat tartalmaznak amire nincs szükségünk, amit nem használunk ki, amelyek indokolatlanul lassítják az oldalt vagy csak plusz adatbázis lekérdezéseket generálnak.

Erre a problémára a megoldást sok esetben, az egyedi sablon jelenti, azaz, hogy hozzáértőkkel iratunk egy olyan sablont, amit ők fejlesztenek nulláról, és azt tartják szem előtt, hogy ez egy nagy forgalmú webáruházhoz készül. Így nem lesz benne semmi, amire nincs szükségünk, de benne lesz minden, amire viszont szükségünk van.

Mennyi látogatóra számítunk?

Ezt a kérdést hagytam a végére, mert a korábbiakkal szemben, talán ez a legkezelhetőbb.

Önmagában a nagy látogató szám nem okoz problémát, egy olyan rendszerben, ami jól cach-elhető, és nem meglepő módon, a WordPress ilyen. Amennyiben, magas látogatottságra számítunk és az oldal szerkezete lehetővé teszi – nincsenek személyre szabottan, dinamikusan generált részek a sablonban – általában több szintű cache-rendszert szoktunk összerakni.

Ez egy gépes környezetben, statikus oldal cache-ből (Super Cache vagy Fastest Cache, esetleg Bat Cache) és egy objektum cache-ből áll, ami belső WordPress objektumokat cach-el. Meglepően sok erőforrást lehet spórolni sokszor a widgetek kimenetének cach-elésével is.

Ha többgépes környezetben fut az oldal, akkor további cache rétegeket bevezetését is megszoktuk lépni, mint a reverz proxyn történő statikus oldal cache (Varnish, nginx).

Konklúzió

A fentiek alapján, ha meg kellene vonni valamiféle konklúziót, akkor az az lenne, hogy nem igazak azok a szirénhangok, miszerint erre, vagy arra nem alkalmas a WooCommerce. Az alkalmassága nagyjából azon múlik, hogy lehetséges-e megfelelő kvalitású fejlesztőket bevonni az oldal elkészítésébe, illetve, hogy megfelelő környezetben van-e üzemeltetve. Mert technikailag a legtöbb góc megszüntethető, és szakértelemmel áthidalható.

Írta:  Lakatos Zsolt