Közeledik az év utolsó 2 hónapja, amik az online kereskedelem forgalmi statiszikái (általánosságban) legmagasabb értékeket adják. Igaz ez a látogatószámra és a szerverekre jutó terhelésre is. Na most, ha lassú a webshop, mert nem készülünk fel a magasabb terhelésre, akkor bizony a webáruház (és kampány) hatékonysága is romlani fog.
A leárazás sikerét könnyű a kampányüzenetnek tulajdonítani, de ha a pénztár akadozik, a termékoldal betöltése lelassul, a marketing nem menti meg a vásárlást. A Deloitte Shopify által hivatkozott kutatása szerint a mobil oldalsebesség 0,1 másodperces javulása 8,4%-kal növelte a konverziós rátát a webáruházakban.
Forgalmi csúcsban azt érdemes vizsgálnod, hogy a kiszolgálás a vásárlói út melyik pontján lassul le. A felhasználói élmény megőrzéséhez a hivatalos keresőóriási ajánlás szerint az e-kereskedelmi oldalaknak 2,5 másodperc alatti LCP (legnagyobb vizuális tartalom megjelenése) és 200 milliszekundum alatti INP (interakciótól a következő festésig mért válaszidő) értéket érdemes elérniük. A pénztár stabilitását azonban külön is ellenőrizned kell.
A rejtett probléma a statikus gyorsítótárazás mögött
A teljes oldalas gyorsítótár jól kezeli az ismétlődő oldalmegtekintéseket. A statikus tartalmak és a termékkategóriák gyorsítótárazhatók, viszont a kosár, a készletellenőrzés és a pénztár dinamikus folyamatok, amelyeket ki kell zárni a teljes oldalas gyorsítótárból. Ezek a személyre szabott műveletek adatbázis-lekérdezéseket és PHP-folyamatokat indítanak. Ezért a legnagyobb terhelést gyakran az egyidejű kosár- és pénztárfolyamatok adják, miközben a termékoldalak még gyorsan betöltődnek.
Egy online elektronikai áruház például hibátlanul kiszolgálta a több ezer egyidejű böngészőt a főoldalon a tavalyi akciók során, mégis összeomlott a rendszer az első tíz percben. A látogatók egyszerre jutottak a vásárlási folyamat azon szakaszába, ahol a készletellenőrző lekérdezések túlterhelték az adatbázist. A vásárlók hibaüzeneteket kaptak a fizetésnél, és a torlódó folyamatok miatt az adminisztrációs felület is elérhetetlenné vált. A főoldal sebessége ezt a kockázatot nem jelezte előre.
Hogyan optimalizáld a szervered a forgalmi csúcsokra
Használj objektum-cache megoldást
A dinamikus vásárlási folyamatoknál az ismétlődő adatbázis-lekérdezések csökkentésével kezdj. A Redis objektum-cache a memóriában tárolt adatokkal hatékonyan csökkenti az ismétlődő adatbázis-lekérdezések számát, de önmagában nem pótolja a hiányzó szerverkapacitást. Ha a pénztárnál az adatbázis a szűk keresztmetszet, egy egyszerűen beállított Redis többet érhet a vásárlási folyamat stabilitásának, mint egy drága, rosszul konfigurált CDN: a WooCommerce gyakran kért adataihoz, például a munkamenetekhez és a termékváltozatok metaadataihoz vezető utat rövidíti le.
Válaszd a megfelelő CDN szolgáltatást
A dinamikus terhelés kezelése mellett a statikus fájlok kiszolgálását is vedd le az eredetszerverről. A developers.google.com elemzése szerint a terheléselosztás, a gyorsítótárazás és a tartalomszolgáltató hálózatok együtt biztosítják az alkalmazások stabil működését a forgalmi csúcsok idején. A CDN élhálózati gyorsítótárazása közvetlenül kiszolgálja a statikus tartalmakat, így a képek, CSS-stíluslapok és JavaScript-fájlok kevesebb terhelést rónak az eredetszerverre. Az edge computing bizonyos dinamikus logikai lépéseket is közelebb vihet a látogatóhoz, de a személyre szabott kosáradatok kezelését külön kell megtervezned.
WordPress specifikus finomhangolások
WordPress környezetben vizsgáld meg a PHP memóriakorlátját, mivel összetett vagy nem jól tervezett sablonoknál, bővítményeknél érdemes legalább 512 MB-ra emelned a wp-config.php fájlban. Korlátozd a Heartbeat API futási gyakoriságát (opció erre: RefiTune optimalizáló bővítmény), ha az adminisztrációs felület és a szerver közötti percenkénti automatikus kommunikáció érdemi terhelést okoz. A felesleges tranziens adatok és korábbi posztverziók törlését tervezett karbantartásként, ellenőrzés után végezd el a kampány előtt. A pénztárfolyamat egyes háttérfeladataihoz a szerver nélküli (serverless) architektúra is alternatíva lehet, ha a tranzakciós adatok és a készletkezelés következetességét biztosítani tudod.
Tesztelés és monitorozás a nyugodt kampányért
A kampány előtti terheléses tesztben a valós vásárlói útvonalat szimuláld: a böngészés mellett a kosárba helyezést és a fizetést is. Így láthatod, hogy a gyorsítótár mögötti adatbázis, a PHP-folyamatok vagy a szerverkapacitás válik-e szűk keresztmetszetté. A teszt közbeni monitorozásnál a processzor- és memóriahasználat mellett a hibákat és a pénztár válaszidejét is figyeld.
A leárazás technikai felkészülést igényel. Én először a személyre szabott vásárlási folyamat terhelését mérném fel, majd ennek alapján állítanám be az objektum-cache-t, a terheléselosztást és a szükséges kapacitást. Ha a kampányrajt előtt végigteszteled a kosártól a fizetésig vezető utat, nagyobb eséllyel veszed észre azt a torlódást, amelyet a gyors termékoldalak elfednek.
Gyakori kérdések a szerveroptimalizálásról
Mikor érdemes elvégezned a terheléses tesztelést az akció előtt?
A tesztelést legalább 2-3 héttel a leárazás előtt javaslom elvégezni. Így elegendő időd marad a feltárt szűk keresztmetszetek javítására, a bővítmények optimalizálására vagy a tárhelycsomag bővítésére anélkül, hogy az éles forgalmat kockáztatnád.
Gyorsíthatja a pénztárat a teljes oldalas gyorsítótárazás?
Nem, a kosár és a pénztár dinamikus folyamat, amit kötelező kizárnod a teljes oldalas cache-ből. Ezeknél a lépéseknél a Redis memóriatár és az adatbázis-lekérdezések tisztítása segít elkerülni a szerver túlterhelését.
Hogyan csökkentheted a WordPress adminisztrációs felületének terhelését?
A Heartbeat API futási gyakoriságának korlátozásával jelentős processzorkapacitást szabadíthatsz fel. Emellett töröld a felesleges tranziens adatokat és a korábbi posztverziókat az adatbázisból a kampány indulása előtt.
Mekkora PHP memóriakorlát szükséges a stabil működéshez nagy roham alatt?
Összetett fizetési modulok és magas látogatószám esetén a PHP memóriakorlátját érdemes legalább 512 MB-ra emelned. Ezt a wp-config.php fájlban tudod beállítani, megelőzve a memóriahiányos rendszerleállásokat.
Elég egy CDN bekapcsolása a szerverösszeomlás megelőzéséhez?
A CDN a statikus fájlok kiszolgálásával drasztikusan tehermentesíti a szervert, de a dinamikus vásárlási folyamatokat nem oldja meg. A teljes védelemhez a háttérfolyamatok és az adatbázis párhuzamos optimalizálása szükséges.