Amikor technikai SEO-ról beszélünk, akkor rendre belefutunk olyan szituációkba, amikor a projekt célja nem a “tökéletes tech SEO” megvalósítása. Hanem egyszerűen a szükséges minimum szint elérése. Itt elég gyakran vannak előre nem látható nehézségek, vagy általunk nem befolyásolható adottságok. Ilyen lehet, amikor egy nemzetközi cégcsoport magyar leánya gyakorlatilag semmit nem tud módosítani a weboldalon a szövegezésen kívül.

Időről-időre persze előjönnek komplexebb (szakmailag izgalmas) kihívások és belefutunk akár évekkel korábbról görgetett, vagy egy weboldal migráció során keletkezett hibába. Ezek javítása jelentős előrelépést hozhat. Ez pedig hozzájárul az organikus forgalom növekedéséhez is. Általánosságban elmondható:

A technikai SEO szükséges, de nem elégséges feltétele az organikus forgalomnak.

A keresőoptimalizálás 3 fő területét mindig összességében érdemes vizsgálni. Ritkán lehet ugyanis eredményt elérni pusztán egy alt text kitöltésével, vagy valamilyen “nice to have” technikai beállítás módosításával. Önmagukban ezek az apró elemek elvétve szoktak ranking-et befolyásoló tényezők lenni. De egyben javítva már sokra mehetünk velük.

Éppen ezért az ilyen típusú technikai eredetű tényezőkre én a weboldal egészségének és a weboldal üzemeltetését (szándékosan nem a weboldal készítőjét) érintő igényesség mérőeszközeként szoktam figyelembe venni. A fejlesztő és a weboldal is lehet tökéletes, ha utána egyébként az üzemeltetés csapnivaló.

Ha egy oldalon még az alt text-ekre is odafigyelnek, akkor tudom, hogy gondos webmester kezek dolgoznak az oldalon, akik tudják mit csinálnak. Ezzel szemben mindig megmosolyogtat amikor a weboldal betöltési sebességére vagy éppen PageSpeed pontszámra próbálunk meg görcsösen ráfeszülni, miközben jelentős hiányosságok vannak mind tartalmi oldalan, mind linkek tekintetében.

Egy technikailag kifogástalan weboldal nem fog több organikus látogatót hozni megfelelő tartalom és linkek nélkül.

A jó SEO nem csak a weboldalon múlik

2022 karácsonyát követő napokban a lazyjack.hu vitorlás és hajós iskola weboldala ellen túlterheléses, úgynevezett DDoS támadás indult. Ennek következtében az oldal a valós felhasználók számára (közel) elérhetetlen volt, a tárhely a kiugróan magas erőforrás felhasználás miatt elkezdte limitálni az oldal elérhetőségét. A napi organikus kattintások száma egyik napról a másikra 80%-kal esett vissza. Jó látható ez a grafikonon is december 28-tól.

Mi a DDOS támadás? “A DDoS (Distributed Denial of Service) támadás egy olyan kibertámadás, amelynek során a támadó több számítógépet vagy eszközt használ arra, hogy túlterhelje egy szerver, hálózat vagy weboldal erőforrásait. Az ilyen típusú támadások célja, hogy a rendszer vagy szolgáltatás ne legyen elérhető a valódi felhasználók számára.” – ChatGPT

A tárhelyszolgáltató felületén indokolatlanul megnőtt php futást tapasztaltunk, így elsőre valamilyen technikai hibára gyanakodtam és a tárhelyszolgáltató is egyértelműen weboldal hibát feltételezett. Egyenesen php fejlesztőt akart javasolni, hogy nézessük át a weboldalt. 😀

Miután több különböző időpontra történő biztonsági mentés visszaállítás sem oldotta meg a problémát az access log fájlokból egész hamar kiderült, hogy valójában többnyire orosz és amerikai IP címekről támadnak. A támadás intenzitása a tárhelyszolgáltatót idézve: “nem volt olyan volumenű, hogy magában a szerver terhelésében észrevehető eltérést generáljon, ami ilyen irányú gyanakvásra adhatott volna okot”, de pont elég volt ahhoz, hogy a weboldal és az adott tárhelyen futó többi oldal (így a thepitch.hu is) is elérhetetlen legyen vagy csak rendkívül lassan tudjuk elérni.

Ekkor kezdett el felértékelődni bennem a weboldal üzemeltetés és az ezzel összefüggésben elérhető optimalizálási lehetőségek fontossága.

Nem mellesleg pedig meg kellett oldani, hogy:

• a mostani támadó IP címeket mihamarabb tiltsuk
• a weboldal elérhetősége helyreálljon, reménykedve hogy az organikus forgalom is helyreáll
• és kialakítsunk egy hatékony védelmet a jövőbeli hasonló támadások ellen.

Itt jött képbe a Cloudflare. De ahhoz, hogy megértsük a Cloudflare eszköztárát érdemes az alapoktól indulni és megérteni mi történik a weboldal mögött?

Mi történik a weboldal mögött?

Amikor megnyitunk egy weboldalt, akkor a domain név gyakorlatilag a weboldalt kiszolgáló szerver IP címét helyettesíti. Ahhoz viszont, hogy a https://thepitch.hu/ URL-t megnyitva a kérésünk a 193.201.191.101 IP címre érkezzen, szükség van egy független információs szolgáltatóra, ami a hozzárendelési szabályokat tárolja. Ezt hívjuk névszervernek (domain name server), illetve az egyes hozzárendelési szabályokat pedig DNS rekord-nak (DNS records).

A DNS rekord segítségével eljutunk a weboldalt kiszolgáló szerverig, aminek több feladata is lehet:

• tárterületet biztosít, tehát tárolja a weboldal forráskódját, a megjelenő képeket, stb.
• feldolgozza a beérkező kéréseket (http requests), vagyis a felhasználói interakciókat értelmezi és a forráskód alapján meghatározott válaszokat ad vissza

A kiszolgáló szerverre később még részletesebben visszatérünk.

Mit tud a Cloudflare?

A Cloudflare globális rendszere a felhasználó és a kiszolgáló szerver közé beágyazódva különböző ingyenes és fizetős megoldásokat kínál annak érdekében, hogy a kapcsolat biztonságos, privát, gyors és megbízható legyen.

Pro tipp: Az ingyenes csomag is tökéletesen használható és megfelelő beállítások mellett jelentős piaci előnyt jelenthet.

DNS

Felmerülhet a kérdés, hogy mennyire gyors a DNS a Clouflare esetében. Ezt itt lehet ellenőrizni.: https://www.dnsperf.com/ A válasz: nagyon. És nem feltétlen csak kiszolgálásban gyors, hanem akár az egyes rekordok életbelépését illetően is.

Tűzfal

A tűzfal célja, hogy a felhasználó és a kiszolgáló szerver közé álljon, tehát a felhasználó a Cloudflare-rel van összeköttetésben, a Cloudflare pedig a háttérben a szerverrel.  Ez lehetővé teszi, hogy különböző tűzfal szabályokat határozzunk meg, amelyek biztonságosabbá tehetik az oldalunkat.

SEO beállítások

Számos olyan SEO beállítást meg lehet oldani, amit eddig mondjuk egy WordPress oldal esetében .htaccess file-ban kellett megoldani. Ilyen a https rewrite valamint a force https is.

SSL tanúsítvány

A Cloudflare ingyenes SSL tanúsítványt biztosít, amit néhány szolgáltatónál a mai napig pénzért / extra szolgáltatásként biztosít.

CDN / cache

A CF Static resources cachelést is biztosít, amit úgy kell elképzelni, hogy a CF lemásolja a statikus fájlokat és nem a kiszolgáló szerver, hanem maga a Cloudflare globális szerver hálózata szolgálja ki ezeket a fájlokat. Ez tehermentesíti a szervert, és javítva a weboldal sebességét is.

GEO replikálás

Megoldható az is, hogy földrajzilag eltérő IP címekről szolgáljuk ki az oldalt, tehát Németországban német IP-ről fogja az oldalt kiszolgálni a CF, Franciaországban francia IP-ről, és így tovább. Ennek számos előnye lehet, akár SEO oldalról is.

Egyedi szabályok

Lehetőség van egyedi szabályok meghatározására, ilyen lehet például:

• meghatározott IP címek, vagy célzott bot-ok tiltása
• a weboldal bizonyos URL-jeinek kiemelt védelme (pl. kötelező captcha a WordPress login oldalra)
• bizonyos IP-ket pedig engedélyezhetünk whitelist (pl. banki rendszerek, irodai IP cím, stb)

Ezeken kívül rengeteg lehetőség van még, de a cél most nem a Cloudflare részletes bemutatása. Viszont az egyértelmű, hogy a Cloudflare ígérete nem csak marketing bullshit. Hanem tényleg gyorsabbá, biztonságosabbá tehetjük a weboldalunk kiszolgálását. Nem mellesleg pedig részben tehermentesíthetjük az oldalunkat kiszolgáló szervert.

Így ki lehetett szűrni a lazyjack.hu elleni DDos támadást, és január elején az organikus forgalom is bár nem olyan dinamikával mint ahogy bezuhant, de szerencsére helyreállt.

A szűk keresztmetszetet viszont innentől kezdve a kiszolgáló szever jelentette. Korábban ígértem, hogy erre a témára még részletesebben visszatérünk.

A tárhelyszolgáltatás anatómiája

A tárhelyszolgáltatások esetén több opciót is érdemes megkülönböztetni:

• megosztott (shared) tárhelyszolgáltatás
• dedikált tárhelyszolgáltatás
• VPS, vagy saját szerver, stb.

Mitől megosztott (shared) a tárhely?

A legtöbben sajnos nincsenek tisztában, vagy nem is érdekli őket, hogy a megosztott tárhely mit jelent a gyakorlatban. A shared tárhelyszolgáltatók egy virtuális vagy fizikai szerveren az elérhető maximum erőforrásokat megosztják a szerveren lévő weboldalak között.

Szolgáltatói oldalról költséghatékony megoldás, hiszen a legtöbb weboldal minimális erőforrást igényel, sok esetben napi néhány tucat látogatót kell kiszolgálni. Azonban, ha a szerveren lévő több weboldal is a szokásosnál nagyobb terhelést kap, akkor ezek szélsőséges esetben egymásra is hatással lehetnek.

Konkrét példa, hogy amikor egy népszerű reggeli rádiós műsorban egy interjú során bemondták egy kis helyi vendégház weboldalának a címét, akkor perceken belül több ezren látogatták meg az oldalt. A shared tárhelyt pedig nem bírta ezt a terhelést. És itt nemcsak a vendégház weboldala halt le, hanem azon a shared tárhelyen lévő összes többi oldalt is rántotta magával.

Ezzel szemben a dedikált tárhely esetén az adott szerver jelentősen kevesebb weboldalt szolgál ki, így a szerver rendelkezésre álló erőforrásait pedig elosztják az a szerveren lévő ügyfelek között. Így a tárhely csomagban meghatározott erőforrások állandóan rendelkezésre állnak terheltségtől függetlenül. Persze ez egyben nagyobb költséget is jelent.

Képzeljük el, hogy a két négybetűs német diszkont áruházlánc egymás melletti üzletei közös (megosztott) pénztárosokkal üzemelnének. Kis forgalom mellett megoldható, a rendelkezésre álló erőforrások költséghatékonyan kerülnek felhasználásra. Csúcsidőszakban viszont a megosztott kasszáknál óriási sor alakulna ki, hiszen a pénztárosok nem győznék a vásárlások feldolgozását.

A csúcsidőszak pedig simán jelentheti a Googlebot aktivitását is.

A drágább tárhely nem mindig jobb tárhely

Logikusnak tűnhet, hogy ahol az oldal elérhetősége kritikus fontosságú (= pénzt termel), legyen szó egy webshopról vagy egy online marketing ügynökség weboldaláról, tegyük át dedikált erőforrásokkal rendelkező prémium tárhelyre.

A shipstore.hu ecommerce oldalunk organikus forgalma az elmúlt 2 évben sokszorosára nőtt és a szezon elejének beköszöntével sorra döntjük meg a napi organikus forgalmi csúcsokat. Ez egyrészt kellemes probléma, másrészt mivel gyakran a dedikált erőforrással rendelkező tárhely ellenére is küzdős volt a weboldal használata, így Paróczi Zsombor, a DONE Digital technológiai vezetőjének segítségét kértem. Zsombor 10+ éve üzemeltet nagy forgalmú weboldalakat.

A terv a következő volt: teszteljük a shipstore.hu weboldalt különböző szerverbeállítások és erőforrások mellett. A teszteket egy erre a célra létrehozott VPS szerveren végeztük el terhelés nélkül, valamint Screaming Froggal szimulált terheléssel.

Mi volt a teszt célja?

A teszt során három fő kérdésre voltunk kíváncsiak:

1. A weboldal technológiai stack-je mennyire erőforrásigényes?
2. Különböző szerver oldali optimalizálások mellett milyen javulás érhető?
3. Hogyan lehet skálázni az oldal üzemeltetését a jövőben?

Ezzel összefüggésben a következő beállításokat teszteltük:

• php verzió (7.4 vs. 8.0)
• Page Caching (WPRocket)
• Object Caching (Redis)
• memcached a session-ök tárolására

Ehhez egy konkrét weboldalt tükröztünk két külön domainre. Pontosabban egy meglévő weboldalt lemásoltunk egy használaton kívüli domainre. És a tesztet lefuttattuk az eredeti verzión és a másolaton is.

WordPress + Divi

Amit jó tudni, hogy a shipstore.hu egy WordPress + WooCommerce alapú oldal, Divi sablont és az ezzel járó Divi buildert használva készítettük el. Bár a hasonló builder-ek (pl. Divi, Elementor, stb.) nem túl gazdaságos megoldások erőforrásigény szempontjából, viszont az elsődleges cél az volt, hogy minimális fejlesztői kapacitás mellett lehessen a hipotéziseknek megfelelően módosítani az egyes aloldalak layout-ját. Ezt pedig tökéletesen hozza.

A tesztek között a weboldalon semmilyen módosítást nem végeztünk, pontosan ugyan azt a verziót használtuk mint az éles környezetben.

Mit vizsgáltunk, mit mértünk?

A korábbi példánál maradva egy weboldal betöltésének folyamata szinte tökéletes hasonlít az Aldi pénztárhoz. Mire is gondolok?

Vannak völgy és csúcsidőszakok, amikor épp több vagy kevesebb látogató van (az üzletben). Az egyes látogatók (vásárlók) egymást követően kerülnek feldolgozásra, ha a feldolgozási idő lassú (amíg a pénztáros lehúzza a vásárolni kívánt termékeket), vagy az adott időpillanatban több a látogató mint amennyit ki tud szolgálni (a pénztáros) akkor az új bejövő látogatók (vásárlók) elkezdenek feltorlódni.

A bejövő kérések (request-ek), vagyis php nyelven megírt feladatokat egy erre a célra betanított úgynevezett worker tudja feldolgozni. Az életből vett példa esetében ők a pénztárosok. Egy tárhely minél több workerrel rendelkezik, annál nagyobb az áteresztő képessége. Tehát ha csupán egy pénztár van nyitva, relatív gyorsan képes feltorlódni a sor, ha 2-4 pénztár van nyitva akkor több felhasználót is képes párhuzamosan kiszolgálni.

A feladatok feldolgozása persze időbe telik, pont mint ahogy a vonalkódok leolvasása is. Ezt hívjuk php futás időnek. Zöldség, gyümölcs és péktermék esetén azonban a pénztárosnak emlékeznie kell a termék kódjára, amit a php memóriában tárol. Ezeket a kódokat egyébként PLU kódnak hívják.

Tudtad például, hogy a napraforgós vekni kódja 765? A 304 meg az idared, a 305 pedig a jonagold alma? Nah, most már igen!

De mi történik, ha egy kódot elfelejt? Adatbázis hívás!

Ha egy kódot elfelejt a pénztáros, akkor fülesen keresztül megkérdez valaki mást (hogy “Icuka, mi a sajtos kifli kódja?”), vagyis valójában egy adatbázis hívást indít. Pár másodperccel később pedig megérkezik a válasz. Ezt nevezzük adatbázis hívásnak és válaszidőnek.

Ezek a hívások persze jelentősen növelik a kiszolgálási időt. A user (vásárló) meg egyre türelmetlenebb lesz. Ebből kiindulva több helyen is bele lehet nyúlni a rendszerbe, hogy javítsuk a folyamatot.

Szerver oldali beállítások:

• felvehetünk több pénztárost (több php worker), így csökkentve a sort
• megtanítjuk a pénztárosokkal a pékáruk kódjait, így az emlékezetükre alapozva (object cache) csökken az adatbázis hívások száma és ideje

Weboldal optimalizációs lehetőségek:

• optimalizáljuk a forráskódot (nem össze-vissza pakolunk a szalagra)
• csökkentjük a szükséges memória igényt (ne telepíts végtelen felesleges WP plugint / kevesebb PLU kódos terméket tartunk, vagy az új termékeket gyorselérésre rakjuk kis kártyán az eladónak)

Összefoglalva, hogy a tesztek összehasonlíthatók legyenek, a következő fő metrikákat rögzítettük:

• sorban állással töltött idő (s)
• php futásidő (s)
• peak memóriahasználat (mb)
• Adatbázis hívások száma (db)
• Adatbázis válaszidő (s)

A mérések során a Query Monitor (https://wordpress.org/plugins/query-monitor/) plugint (szerver oldali mérés), valamint a Chrome böngésző beépített fejlesztői konzolját használtuk (kliens oldali mérés). Egy mérés nem mérés, így az első mérés eredményét mindig eldobtuk, majd rögzítettük a következő 3 mérés eredményét.

Ezen kívül kíváncsiak voltunk a teljes szerver (VPS) által felhasznált erőforrásokra, így:processzor használatra (CPU)memória igényreés a sávszélességre (adatátvitel mértékére).

Eredmények

A tesztek során 5 különböző URL-t vizsgáltunk, ezek pedig tudatosan lettek kiválasztva:

URL	Tartalom típusa	Miért?
https://shipstore.hu	főoldal	bár a kezdőlap a Ship Store weboldal látogatói szempontjából nem különösebben látogatott oldal, mivel a szintetikus teszteket mindig főoldalra szokás elvégezni így bekerült a listába
https://shipstore.hu/webshop/horgony/	kategória oldal	egyszerű kategória oldal, két tucat termékkel
https://shipstore.hu/webshop/rozsdamentes-veretek/	kategória oldal	egyszerű kategória oldal, több száz termékkel
https://shipstore.hu/raymarine-muszerek/	kategória gyűjtő	kategória oldalnak tűnik, de valójában egy kategória gyűjtőről, landing page-ről beszélünk ami több kategóriára vonatkozóan futtat és jelent meg termékeket (adatbázis kéréseket követően)
https://shipstore.hu/wp-admin/edit.php?post_type=product	WordPress Admin	a WooCommerce admin felületen az összes (2000+) termék listázása

Bázis értékek

Mit tapasztaltunk terhelés nélkül?

• Gyakorlatilag egyedüli látogató voltam ebben az esetben
• A feldolgozás nem volt extrém lassú
  • a php 7.4, php 8.0, php 8.1 valójában semmi tapasztalható teljesítmény különbséget nem hozott (a mostani legfrissebb verzió egyébként 8.2 a php-ből)

• A php memória használat mérete 40-60mb
  • Ez fontos infó a szerver oldali php memory_limit beállításához
• Az adatbázis kifejezetten gyors, a requestek száma változó
• A Cloudflare CDN és static cache-et alapul vettük, a Cloudflare analitikája elég jó
• Page cache nem volt bekapcsolva (WPRocket)

Terhelés nélkül (gyakorlatilag látogató nélküli eset)

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	0.34	1.32	54.7 MB	219	0.08
https://shipstore.hu/webshop/horgony/	0.28	1.73	60.1 MB	323	0.1
https://shipstore.hu/webshop/rozsdamentes-veretek/	0.27	0.99	56.0  MB	321	0.09
https://shipstore.hu/raymarine-muszerek/	0.31	1.56	57.9 MB	400	0.1
https://shipstore.hu/wp-admin/edit.php?post_type=product	0.44	1.3	42.4 MB	674	0.21
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0

Mit tapasztaltunk szimulált terhelés alatt?

• A feldolgozás ideje minimálisan lassult csak
• Memóriahasználat érdemben nem változott
• Adatbázis queryk száma szintén nem változtak (meg is lepődtünk volna :D)
• Adatbázis láthatóan azért lassult

Viszont érezhetően mégis lassabb lett az oldal? Miért? Hát a sorban állás ideje nőtt. Pont mint munkaidő végén az Lidl-ben!

Szimulált terhelés alapjai

Szimulált, vagy mesterséges terhelés esetén a Screaming Frog segítségével elkezdtük bejárni a weboldal összes aloldalát, vagyis a főoldal megnyitását követően minden internal linkre “rákattintottunk” és betöltöttük10 request/s tempóval estünk neki az oldalnakuser agentként pedig valódi usert és Googlebotot is szimuláltunk.

Szimulált terheléssel

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	7.46	1.71	55.2 MB	208	0.21
https://shipstore.hu/webshop/horgony/	8.09	1.53	56.6 MB	311	0.26
https://shipstore.hu/webshop/rozsdamentes-veretek/	7.33	1.61	57.2  MB	313	0.13
https://shipstore.hu/raymarine-muszerek/	9.61	1.92	58.8 MB	363	0.22
https://shipstore.hu/wp-admin/edit.php?post_type=product	7.71	2.03	45.7 MB	663	0.51
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0

WP Rocket

Bekapcsoltuk a WPRocket plugint. A WP Rocket valójában page caching megoldás, tehát a nem dinamikusan változó oldalakat statikusan tárolja így betöltéskor ezt szolgálja ki a felhasználók számára.

Cache típusok Sok fajta cache-t ismerünk. Pl:Browser cache (css, javascript, képek)Page cache (= site cache) (statikus oldalak)Static cache (+ én ide sorolnám a CDN-t is) (css, javascript, képek)Object cache (adatbázis query-k)Opcache (php feldolgozás)

Mit tapasztaltunk WPRocket-tel terhelés nélkül?

• átlagosan 12%-os javulás a php futás időben
• átlagosan 18%-os javulás a sorban állással
• a memória és adatbázis használatot elvileg a WPRocket nem befolyásolja, nem is tapasztaltunk érdemi különbséget

Terhelés nélkül (gyakorlatilag látogató nélkül)

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	0.21	1.06	56.9 MB	214	0.05
https://shipstore.hu/webshop/horgony/	0.32	1.12	58.1 MB	320	0.1
https://shipstore.hu/webshop/rozsdamentes-veretek/	0.22	0.95	58.2  MB	319	0.09
https://shipstore.hu/raymarine-muszerek/	0.23	1.32	60.2 MB	404	0.11
https://shipstore.hu/wp-admin/edit.php?post_type=product	0.34	1.49	44.2 MB	674	0.17
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0, WPRocket

Mit tapasztaltunk szimulált terhelés alatt?

• php futásnál átlagosan 7% javulás a WPRocket nélküli szimulált terheléshez képeset
• sorban állás tekintetében 9% javulás
• jól látszik hogy bár milliszekundum-os nagyságrendről beszélünk, de az adatbázis válaszidő átlagosan 243%-al romlott a terhelés nélküli állapothoz képest

Nem ettől lesz lassú, vagy gyors az oldalunk de ha már lehet akkor próbáljunk meg itt javítani az értékeken.

Szimulált terheléssel

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	7.05	1.60	60.0 MB	214	0.19
https://shipstore.hu/webshop/horgony/	7.09	1.50	61.7 MB	317	0.15
https://shipstore.hu/webshop/rozsdamentes-veretek/	6.84	1.48	62.2  MB	319	0.24
https://shipstore.hu/raymarine-muszerek/	7.46	1.87	62.4 MB	369	0.26
https://shipstore.hu/wp-admin/edit.php?post_type=product	7.84	1.69	49.1 MB	673	0.31
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0, WPRocket

Redis

A Redis szintén egy cache megoldás, viszont ez esetben a gyakori adatbázis hívásokat cacheljük így gyorsítva az amúgy sem túl lassú adatbázis válaszidőt.

Mit tapasztaltunk Redis-szel terhelés nélkül?

• Az adatbázis hívások száma 9-17 között mozgott
• Az adatbázis válaszidő olyan alacsony, hogy a query monitor plugin nem tud ennél pontosabb értéket visszajelezni
• Mivel a Redis a sorban állást és a php futást sem befolyásolja érdemben így ezeket a könnyebb értelmezhetőség miatt kihagytuk a táblázatból

Terhelés nélkül (gyakorlatilag látogató nélkül)

URL	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	9	0.01
https://shipstore.hu/webshop/horgony/	14	0.02
https://shipstore.hu/webshop/rozsdamentes-veretek/	16	0.01
https://shipstore.hu/raymarine-muszerek/	17	0.02
https://shipstore.hu/wp-admin/edit.php?post_type=product	46	0.03
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0, WPRocket, Redis

Mit tapasztaltunk szimulált terhelés alatt?

• Terheléstől függetlenül az adatbázis indokolatlanul gyors maradt
• Az adatbázis hívások száma 17-32 közé emelkedtek

Szimulált terheléssel

URL	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	17	0.02
https://shipstore.hu/webshop/horgony/	18	0.01
https://shipstore.hu/webshop/rozsdamentes-veretek/	18	0.02
https://shipstore.hu/raymarine-muszerek/	32	0.02
https://shipstore.hu/wp-admin/edit.php?post_type=product	52	0.03
Beállítások: 2 core, 2 worker, 256MB memory_limit, php 8.0, WPRocket, Redis

Az adatbázisban rejlő lehetőségeket kimaxoltuk, viszont a látogatók kiszolgálását illetően nem vagyunk még maradéktalanul elégedettek. Nyúljunk bele a szerver beállításokba.

We’re hiring!

Az eddigi teszteknél egy tipikus shared hosting szolgáltatói beállítással mentünk, mindösszesen 2 workerrel. Ez a gyakorlatban azt jelentette, hogy a 2 worker együttesen 1.6 URL/s tempóval szolgálta ki a felhasználókat.

De nyissunk meg több pénztárt, használjuk ki a szerver összes CPU core-ját.

8 core + 7 worker

A szerveren 8 CPU core állt rendelkezésre, ebből 1 core-t az adatbázisnak dedikáltunk így a maradék 7 core-hoz beállítottunk 7 workert.

Mit tapasztaltunk terhelés nélkül?

• A php futás időt sikerült 13-45%-kal csökkentenünk még a korábbi terhelés nélküli verzióhoz képest is
• Sorbanállás is gyakorlatilag a hálózati adatforgalom miatt van csak

Terhelés nélkül (gyakorlatilag látogató nélkül)

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	0.2	1.14	56.4 MB	9	0.01
https://shipstore.hu/webshop/horgony/	0.19	0.95	58.3 MB	14	0.01
https://shipstore.hu/webshop/rozsdamentes-veretek/	0.2	0.95	58.7  MB	15	0.01
https://shipstore.hu/raymarine-muszerek/	0.2	1.25	59.7 MB	29	0.02
https://shipstore.hu/wp-admin/edit.php?post_type=product	0.39	1.3	48.1 MB	46	0.02
Beállítások: 8 core, 7 worker, 256MB memory_limit, php 8.0, WPRocket + Redis

Mit tapasztaltunk szimulált terhelés alatt?

• A php futás lassult egy picit, itt a szerver azért már érezhetően megizzadt
• De sorbanállás gyakorlatilag nem keletkezett
• A szimulált terhelés esetén másodpercenként 10 szálon indítottunk új kérést a weboldal felé, amit a szerver 5.2 URL/s tempóval szolgált ki

Szimulált terheléssel

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	1.42	2.07	58.5 MB	16	0.02
https://shipstore.hu/webshop/horgony/	0.59	1.83	59.4 MB	18	0.01
https://shipstore.hu/webshop/rozsdamentes-veretek/	1.13	1.82	59.6  MB	18	0.01
https://shipstore.hu/raymarine-muszerek/	0.83	2.22	60.3 MB	31	0.02
https://shipstore.hu/wp-admin/edit.php?post_type=product	1.64	2.34	55.85 MB	54	0.04
Beállítások: 8 core, 7 worker, 256MB memory_limit, php 8.0, WPRocket + Redis

8 core + 16 worker

Az utolsó teszt során már inkább a kíváncsiság hajtott minket, a teljesítmény már korábban is bőven jó volt. De mi történne, ha egy pénztárhoz (CPU core) 2 pénztárost ültetnénk?

Terhelés nélkül itt már nem volt értelme az adatokat ellenőrizni, így hát jöjjön egyből a terhelés.

Mit tapasztaltunk szimulált terhelés alatt?

• A szerver izzadt tovább, sorbanállás továbbra sem volt. Annyira nem, hogy a szerver 8.88 URL/s tempóval szolgálta ki a látogatókat ami a másodpercenként indított 10 látogató terhelés mellett már szerintünk is túl jó érték volt. Azt érdemes még hozzátenni, hogy az átlag user session ideje ennél jelentősen lassabb, hiszen a valódi felhasználók jó esetben megnézik a tartalmat is nem csak vakon kattintgatnak a linkekre.

Szimulált terheléssel (10 látogató / s)

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)
https://shipstore.hu	0.21	1.44	57.0 MB
https://shipstore.hu/webshop/horgony/	0.21	1.41	59.0 MB
https://shipstore.hu/webshop/rozsdamentes-veretek/	0.21	1.35	59.4  MB
https://shipstore.hu/raymarine-muszerek/	0.2	1.7	60.3 MB
https://shipstore.hu/wp-admin/edit.php?post_type=product	0.39	1.95	48.2 MB
Beállítások: 8 core, 16 worker, 256MB memory_limit, php 8.0, WPRocket + Redis

Így a tesztet megismételtük másodpercenként 20 látogató terheléssel.

Mit tapasztaltunk az extra szimulált terhelés alatt?

• Az adatbázis továbbra is gyorsan dolgozott
• Ekkora terhelés mellett a php futás idő is majdnem duplájára nőtt, illetve bár a várakozási idő is háromszorosára nőtt. De felhasználói oldalról ezek a betöltési sebességek is még teljesen használható weboldalt eredményeztek. Nem volt villámgyors, de az átlag user-nek fel sem tűnt volna.

Szimulált terheléssel (20 látogató / s)

URL	Sorban állás (s)	PHP futás (s)	Peak memóriahasználat (mb)	Adatbázis query (db)	Adatbázis válaszidő (s)
https://shipstore.hu	0.61	2.5	57.0 MB	16	0.03
https://shipstore.hu/webshop/horgony/	0.64	1.9	59.3 MB	14	0.01
https://shipstore.hu/webshop/rozsdamentes-veretek/	0.75	2.3	59.7  MB	15	0.02
https://shipstore.hu/raymarine-muszerek/	0.71	1.93	60.3 MB	17	0.02
https://shipstore.hu/wp-admin/edit.php?post_type=product	1.05	2.9	48.2 MB	52	0.02
Beállítások: 8 core, 16 worker, 256MB memory_limit, php 8.0, WPRocket + Redis

Ugyanakkor a másodpercenként 20 látogató esetén a szerver már rendesen izzadt, lényegében ez volt az elméleti maximum terhelés, amit a szerver még ki tudott szolgálni. Az összes processzor mag 100%-on dolgozott, ekkor készül a kedvenc screenshot-om is.

A szerver ekkor Cloudflare mögül 35 Mbit/s sávszélességet generált.

Csak összehasonlításként: 130 weboldalt kiszolgáló szerver átlagos hétköznapi adatforgalma 4-6 Mbit/s között mozog, időszakosan 10-11 Mbit/s csúcsokkal. A fenti értéket mi a shipstore.hu weboldal terheléses tesztjével generáltuk.

Összegzés

Ha megnézzük azt, hogy milyen forgalmat bonyolítottunk le a teszt során, akkor Cloudflare-en mérve ezt látjuk az eredeti weboldalon:

Ezek pedig a másolat oldalon mértük a teszt(ek) során. Itt 9.28 GB adatforgalmat generáltunk. Ha pusztán adatforgalom alapján becsüljük, akkor a tesztek során közel 12 000 unique user-nyi terhelést küldtünk rá az oldalra néhány óra leforgása alatt.

Ezen a grafikonon is látható a Bandwith és annak a megoszlása a copy weboldalon.

Mennyi erőforrásra van szükség egy weboldalhoz?

Jogosan merül fel a kérdés, hogy akkor végülis mekkora erőforrásra (és mennyi vasra) van szükség egy weboldal normális kiszolgálásához?

Saját magam számára ezeket a hüvelykujj szabályokat írtam fel:

• kis számolással relatív egyszerű meghatározni, hogy mekkora erőforrásra van szükség
• php memória igény = workerek száma x memóriahasználat query monitorban mérve
  • pl: 2 worker x 60-70M, tehát simán php memory_limit-ben 128MB-256MB között még egy shipstore.hu is elvan
• adatbázis memória igény = adatbázis dump x 3
  • tehát a shipstore SQL adatai 235MB, ezt hárommal szorozva kb. 768MB ideális memóriára van szükség
• teljes memória igény = php memória igény + adatbázis memória igény
  • tehát kb. 1.5 GB memória amit a shipstore igényel, hogy kényelmesen el is férjen

• az éles oldal a teszt napján 900 unique user-t szolgált ki, ez 721MB adatforgalmat generált
  • Ebből 277 MB cached volt, tehát a szervernek csupán 444 MB-ot kellett bírnia.

Nyilván vannak olyan extrém esetek, amikor rövid idő alatt jelentős terhelés érkezik egy oldalra. De ezek nagy részét sokszor egyébként vagy előre lehet jelezni vagy ha nem, akkor gyorsan lehet cselekedni, ha van egy tervünk rá.

Engem például a mai napig meglep, hogyan képes szétfagyni egy Neptun rendszer vagy egy adóbevallás, pályázati jelentkezés portál normál, valós userek által történő terhelés alatt. A válasz elég egyszerű: jellemzően rosszul van méretezve a rendelkezésre álló erőforrás. Emellett vagy nem, vagy csak lassan és körülményesen bővíthető a setup. Ami azért furcsa, mert mi a teszt során például egyik este vacsora közben valós időben tudtunk ki-be kapcsolni cpu coret vagy workereket, úgy hogy 3 különböző helyen ültünk, a szerver pedig nem is Magyarországon van. Szóval megfelelő hozzáértéssel és felkészüléssel, azért nem megoldhatatlanok ezek a feladatok.

Konklúzió

Az elsődleges feladat nyilván az volt, hogy megóvjuk az üzletileg fontos oldalainkat a külső támadásoktól. Ezt sikerült is megcsinálni. Menet közben pedig több olyan dolgot szeretem volna tesztelni, ami mindig is érdekelt, foglalkoztatott.

A teszt után az alábbi megállapításokat lehet tenni.

• A sok erőforrás nem meglepő módon sokat is bír. Ebben nincs azért óriási újdonság.
• A drágább tárhely viszont nem feltétlenül lesz jobb tárhely. És nem fog neked jobb oldalsebességet biztosítani. Ugyanis lehet, hogy olyan plusz erőforrásért fizetsz, amire neked pont nincs szüskéged.
• A page cache fontos, mert elég sokat lehet rajta fogni, például egy WPRocket segítségével. De önmagában maga a page cache még nem oldja meg a rossz szerver beállításokat vagy a kevés erőforrást.
• Az object cache egy közepesen izgalmas tényező, valahol 10-30 ms fogható vele. Ami önmagában nem sok, de a több tényezővel együtt már érdemes vele foglalkozni.
• A php workerek száma fontosabb, mint a memória. Ez azért kritikus, mert néhány szolgáltató ezt pont fordítva gondolja. Egy cpu core kényelmesen megold akár a több workert is. És hiába fizetsz elő nagyobb csomagra, amiben több memória van, számodra lehet nem is a memória a szűk keresztmetszet.
• A weboldalaink technikai setupját és biztonságát jelentősen sikerült javítani. Emellett eltelt 9 hónap és azóta se történt semmilyen terheléses támadás. Vagy ha lett is volna, akkor a Cloudflare azonnal kíszűrte azokat.

Ha te is tapasztaltál már olyat, hogy az oldalad nagyon lassú, pedig elvileg „minden rendben van” vele, vagy érte már az oldaladat terheléses támadás, akkor érdemes végignézni a fenti leírást és megfogadni belőle a fő tanácsokat.

Ha pedig szükséged van valakire, aki ránéz az oldaladra tech SEO oldalon, esetleg ellenőrzi hogy állná a sarat egy esetleges támadás ellen, akkor vedd fel velünk a kapcsolatot!