Amikor egy weboldal lassú, elérhetetlen, vagy éppen összeomlik a látogatók rohama alatt, a tulajdonosok első reakciója szinte reflexszerű. Hibajegyek röpködnek, telefonok izzanak, és a hangnem gyakran a kétségbeesés és az agresszió keveréke. Pedig az esetek döntő többségében a probléma gyökere nem a szerverparkban, nem a hálózati kábelekben és nem is a szolgáltató rosszindulatában keresendő. A rosszul beállított weboldal, rosszul kezelt erőforrások és a technikai ismeretlenség, ami nagyon sokszor elrontja az online jelenlétet.

A kliens oldali gyorsítótár és a tömörítés hiánya

Kezdjük az alapoknál, azon a ponton, ahol a felhasználó találkozik a tartalmaddal. A modern web nem szöveges fájlok cseréjéről szól csupán. Nagy felbontású képek, komplex JavaScript könyvtárak, CSS stíluslapok és betűtípusok utaznak a szerver és a látogató böngészője között. Ha te nem állítod be megfelelően a kliens oldali gyorsítótárazást (browser caching), azzal gyakorlatilag minden egyes oldalletöltésnél arra kényszeríted a látogató eszközét, hogy újra és újra töltse le ugyanazt a logót, ugyanazt a háttérképet, ami már tíz perce is ott volt.

Ez nem csupán a látogató adatforgalmát pazarolja, hanem a szervered erőforrásait is égeti. Minden egyes felesleges HTTP kérés egy újabb folyamatot indít el, memóriát foglal, és processzoridőt igényel. Ha ehhez hozzávesszük a tömörítés (Gzip) hiányát, a katasztrófa borítékolható. A tömörítés nélküli adatátvitel olyan, mintha egy kamiont küldenél el egyetlen borítékért. A hálózat telítődik, az oldal betöltési ideje drasztikusan megnő, a felhasználói élmény pedig a nullára zuhan. Egy megfelelően beállított WWW Domain a szöveges tartalmakat (HTML, CSS, JS) akár 70-80 százalékkal kisebb méretben is képes átküldeni, ha a tömörítés aktív.

Kapcsolatok, folyamatok és az adatbázis

Lépjünk beljebb a gépházba. Sokan abban a tévhitben élnek, hogy a „korlátlan” tárhely azt jelenti, hogy a fizika törvényei nem vonatkoznak rájuk. Minden webszervernek, legyen az Apache, Nginx vagy LiteSpeed, vannak fizikai és szoftveres korlátai. Itt jön képbe az egyidejűleg futtatható feldolgozó folyamatok (worker processes/handlers) és az adatbázis kapcsolatok száma.

Képzeld el a weboldaladat egy étteremként. A pincérek a feldolgozó folyamatok (például PHP workerek). Ha van 10 pincéred, de bejön 50 vendég egyszerre, 40 embernek várnia kell az ajtóban, amíg egy pincér felszabadul. Ha a kódod rosszul van megírva (például egy végtelen ciklusba fut, vagy egy SQL lekérdezés másodpercekig tart) az a „pincér” foglalt marad. Egy rosszul optimalizált weboldal pillanatok alatt elfogyasztja az engedélyezett processz számot (Entry Processes), és a látogatók nem az oldaladat látják, hanem egy folyamatosan forgó betöltés animációt, majd 50x hibaüzenetet.

Még kritikusabb a helyzet az adatbázis kapcsolatoknál. A modern CMS rendszerek (WordPress, Joomla, Magento) minden oldalletöltésnél tucatnyi kérdést intéznek az adatbázishoz. Ha nem zárod le a kapcsolatokat, vagy nem használsz perzisztens kapcsolatokat, az adatbázis szerver eléri a max_connections limitet. Ilyenkor hiába van szabad memória, hiába van erős processzor, az oldal megáll, mert az ajtó zárva. A kapcsolatok számának maximalizálása nem azt jelenti, hogy a végtelenségig emeljük a limitet a konfigurációban, hanem azt, hogy a kódot úgy írjuk meg és a szervert úgy hangoljuk, hogy a meglévő kapcsolatokat a lehető leghatékonyabban használja ki.

HTTP/HTTPS DDoS támadások

A rossz beállítások nem csak lassulást okoznak, hanem sebezhetővé is tesznek. A Distributed Denial of Service (DDoS) támadások világában ma már nem csak a „cső eldugítása” a cél (volumetrikus támadás), hanem az alkalmazás réteg (Layer 7) térdre kényszerítése.

Egy HTTP/HTTPS flood támadás során a támadó nem egyszerűen szemetet küld a hálózaton, hanem validnak tűnő kéréseket indít az oldalad (szofisztikáltabb támadás esetén a legerőforrás-igényesebb részei) felé. Például folyamatosan a keresőmezőt használja, vagy egy olyan oldalt hív le, ami bonyolult adatbázis műveleteket végez. Ha a weboldalad nincs gyorsítótárazva, és minden kérésnél újra legenerálja a tartalmat, a tárhely pillanatok alatt „összeomlik”. Egy jól beállított gyorsítótár (legyen az szerver oldali, egyszerű fájl alapú, vagy CMS bővítmény, mint WP Fastest Cache) képes arra, hogy ezeket a kéréseket előre generált adatokból szolgálja ki anélkül, hogy az adatbázist vagy a PHP értelmezőt is terhelné.

Egy ilyen támadás alatt a tárhely erőforrás használata (CPU, RAM) az egekbe szökik. Ha nincs megfelelő védelem és limitálás beállítva, a támadás sikeres lesz, és a szolgáltatás leáll. Itt válik kritikussá, hogy megértsd azt, hogy a támadók a te figyelmetlenséged is használják fegyverként ellened.

Az osztott tárhely és a „zajos szomszéd”

Térjünk át egy kényes, de megkerülhetetlen témára. Az osztott tárhely (shared hosting) valóságára. Amikor évi pár ezer vagy pár tízezer forintért bérelsz tárhelyet, nem egy saját szervert kapsz, hanem egy „lakást” egy hatalmas társasházban. Több száz másik felhasználóval osztozol a processzoron, a memórián és a lemezműveleteken.

Ebben a környezetben, ha valaki nem optimális beállítások mellett használja a tárhelyét (például egy hibás bővítmény miatt a WordPress oldala másodpercenként százszor próbál írni az adatbázisba, vagy egy beragadt script folyamatosan 100% CPU-t kér), azzal közvetlenül károsítja a többi felhasználót. Bár a modern rendszerek (mint a CloudLinux) próbálják elszigetelni a felhasználókat, a lemezműveletek és az adatbázis szerver terhelése gyakran közös.

Aki miatt a szerver „load”-ja az egekbe szökik, az a rossz szomszéd, aki éjjel kettőkor falat fúr.

A szolgáltató szerepe

Amikor a szolgáltatód jelzi, hogy az oldalad túlterheli a szervert, hogy optimalizálnod kellene az adatbázisodat, vagy hogy a scriptjeid biztonsági kockázatot jelentenek, azt nem azért teszi, hogy bosszantson. Ők látják a szerveroldali metrikákat, amiket te nem. Látják a kernel szintű várakozási időket, az I/O várólistákat és a memóriaszivárgást.

A web folyamatosan változik. Egy frissítés, egy új botnet támadása, vagy egy adatbázis tábla méretének növekedése egyik napról a másikra megváltoztathatja az oldalad erőforrás-igényét.

Ha tanácsot adnak, hogy kapcsolj be gyorsítótárazást, frissíts PHP verziót, vagy indexeld újra az adatbázis tábláidat, akkor érdemes hallgatni rájuk. Az együttműködés a kulcs a stabilitáshoz. A dac és a tagadás csak további problémákat szül, ami egyik fél számára sem előnyös.

Teljes elkülönítés

Ha a max_execution_time = 10000-re és memory_limit = 1024M -re úgy tekintünk, mint alapjog minden egyes script futtatásához, és a végtelen ciklusra csak egy programozói stílusjegyként, akkor érdemes lehet megpróbálni ezt VPS szolgáltatás keretein belül. Ki lehet kapcsolni a tűzfalat. Lehet hagyni, hogy az adatbázis megegye az összes RAM-ot, és a swap fájlba írjon, amíg a lemez I/O bírja. A VPS a „szabadság földje”. Itt mindenki saját maga rendszergazdája lehet. Nincs közvetlen „szomszéd”, akit zavarni lehet, csak az egyén és a linuxos terminál villogó kurzora. Ez egy nagyon erős eszköz lehet osztott tárhellyel szemben, ha megfelelő kezekben van… egyébként ez mégannyira sem fog működni.