Legtöbbször azért kesergünk, mert a keresőrobotok nem indexelik elég gyorsan a tartalmainkat. Előfordul azonban olyan eset is, amikor a robotok oly mértékben esnek neki oldalaknak, hogy ezzel már a valós látogatók kiszolgálását is veszélyeztetik.
Egy átlagos webszerver számára egy pluginekkel középsúlyosan fertőzött WordPress lap létrehozása egyáltalán nem egyszerű feladat. A webszervernek akár 1/10 másodperc is szükséges a lekért oldal létrehozásához. Ha ezt megfordítjuk, akkor látható, hogy másodpercenként 10 oldal lekérése fölött már egy mezei WordPress lappal is lehetnek problémáink.
Nyilván rengeteg terhelés csökkentését célzó megoldást használunk, de nyers számok mégis ezek. Ilyen körülmények között kissé abszurd, ha a keresők robotjai időnként jócskán fölé mennek ezeknek a számoknak.
Mi a keresők üzemeltetőinek a válasza?
A fenti problémát számtalanszor jelezték az érintett keresők, a Google és a Bing üzemeltetői felé. Ők erre rendszerint laza eleganciával kinyilatkoztatják, hogy ez nem okozhat problémát. Szerintük, ha túl sok kérés, akkor a szerver majd 500-as kóddal válaszol, és a keresőrobotok ezt feldolgozva majd csökkentik a kérések számát. Szerintük nincs itt semmi látnivaló, mindenki haladjon tovább. Kár, hogy ez nem ilyen egyszerű.
Néhány keresőbot lehetőséget ad ugyan egy „Crawl-delay” érték megadására a robots.txt fájlban, amiben a két kérés között eltelt minimális időt adhatjuk meg másodpercben. Ám ezt pont a leginkább problémás robotok nem veszik figyelembe. A Googlebot, a Bingbot és a Yandexbot éppúgy semmibe veszik ezt.
Láttak már ezek az emberek webszervert?
Meg kell kérdeznem, hogy akik szerint normális az 500-as státuszkódig terhelni egy szervert, azok egyáltalán láttak már ilyen webszervert működni? Az 500-as kód ugyanis nem úgy keletkezik, hogy a webszerver kitalálja, hogy neki a következő kérés már picit sok volna, és nosza, dob egy 500-as kódot. Ez a hibakód már igencsak arra utal, hogy a szerveren kezelhetetlen hiba történt, pl. belefutott a beállított limitekbe, vagy épp kifogyott az erőforrásokból.
A felhasználók már jóval az 500-as hibakódok megjelenése előtt tapasztalhatnak problémát, pl. hogy a lap csak nagyon-nagyon lassan vagy egyáltalán nem töltődik le. Ha nem dedikált webszerverről beszélünk, akkor annak is komoly esélye van, hogy a szerveren kiszolgált valamennyi lap látogatóit érinti a probléma. Mindezt még azelőtt, hogy a probléma a robotok felé küldött 500-as kódban is megnyilvánulna.
Pontosan hogyan is működik ez a valóságban?
Egy webszerver egy adott weblapból másodpercenként X kérést képes kiszolgálni, ha a pillanatnyi kérésszám nagyobb, mint X, akkor gond van. Ezt a gondot pedig a felhasználók a saját bőrükön megtapasztalni, legyen bármennyire is gyors-reagálású az üzemeltető csapat.
- A feltorlódó kérések szépen sorban állnak a webszerveren, amely igyekszik ezeket teljesíteni a beérkezésük sorrendjében.
- Mivel a kiszolgálás tovább tart, mint az érkező kérések között eltelt idő, a várakozó kérések sora egyre hosszabbá válik.
- A látogatók azt tapasztalják, hogy a böngésző „homokórázik„. Néhányan erre a frissítés gomb nyomkodásával reagálnak, amivel a webszerverre érkező kérések számát még tovább növelik.
- Ha a várakozó sor hossza eléri a beállított maximális értéket, vagy a szerver kifogy az erőforrásokból, akkor az új kérésekre már csak hibakódokkal válaszol a webszerver. Rosszabb esetben már azokkal sem. Viszont egyáltalán nem valószínű, hogy a problémát kiváltó keresőrobotok kapják az első hibakódokat.
Talán látható, hogy mire a keresőrobot az első 500-as hibakódot megkapja, addigra már dühös, csalódott felhasználók hada fordulhat el a weboldaltól.
Mi a megoldás?
A PHP, SQL és WP cache és hasonló megoldások alapvetőek, de a fenti problémán egyáltalán nem biztos, hogy önmagukban segítenek. Több erőforrást adhatunk a szervernek, bár kissé nonszensz állapotnak érzem azt, amikor a webszerver terhelésének legjelentősebb részéért a robotok felelősek.
Lehet, hogy a látogatóknak készítünk weblapot, de az biztos, hogy a webszerverek méretezésénél csak kerekítése értékként kell kalkulálnunk velük. A keresőrobotok itt mindenképp elfoglalták az első helyet.
