Jak dovedou internetový roboti ovlivnit chod celého serveru

Dnes Vám popíši, jak hodně může ovlivnit rychlost načítání vašich stránek. Návštěva indexovacích robotů a také, že jejich invaze není na první pohled vidět.

Své stránky mám na virtuálním serveru v datovém centru. Na němž běží všechny důležité systémy a také několik mých webů. Mimo jiné i projekt agregatorblogu.cz. Oproti klasickému hostingu má vlastní virtuální server několik výhod, ale také jak už to bývá i nedostatků. Jste vlastními pány nad celou konfigurací serveru, takže můžete dle libosti volit verzi databází, prostředí pro spouštění skriptu, ale také množství webových prezentací. U hostingu sice platíte za webovou adresu, nicméně zato většinou dostanete odladěný systém, nastavené všechny hodnoty nutné pro chod webových prezentací a také například pravidelné zálohování. Já jsem se od dob stěhování svého fyzického serveru prostě chtěl o své prostředí starat sám a tak Vám teď mužů popsat celý postup, jak jsem odhaloval problém z pomalou odezvou svých webových stránek.

Nejprve jsem pomalejšímu načítání stránek nevěnoval pozornost. Přikládal jsem to prostě pomalejšímu internetu v různých lokalitách i občas línému prohlížeči, který má u mě vždy otevřeno opravdu hodně dalších stránek. Když se mi ovšem ozvali ostatní, že se stránky načítají nějak zvláštně, začal jsme zjišťovat co se děje. První bylo ověření, co vlastně samotný server dělá tak, že jsem se k němu přihlásil a sledoval, jak pracuje s přidělenými zdroji. Tedy s pamětí a procesorem. Zjistil jsem že co 15 – 30 vteřin je procesor vytíženy na 100%. To bylo zvláštní, protože i náročnější skripty se načítají pouze jednou za minutu, interval byl tedy podezřelý. Provedl jsem instalaci aktualizaci i restart serveru ale nic nepomohlo.

Po několika minutách sledování bylo jasné, že se nejedná o náhodné zatížení, ale o systematický problém který prostě vytěžuje procesor. Dle všeho se o zátěž starala databáze. Vše tedy ukazovalo na to, že problémy s výkonem způsobuje nějaký web, který je na serveru umístěn. Podezření padlo na web Agregátorblogu.cz ten totiž má automaticky spouštěné procesy patřící robotovy zajištujícímu načítání obsahu stránek. Také jeho databáze je docela velká a s daty pracuje velmi dynamicky, takže nějaký skript mohl být klidně napsaný špatně. Vydal jsem se tedy do rozhraní pro databázi, abych si zjistil co v době vytížení procesoru databáze vlastně dělá.

Výsledek byl překvapením, protože analýza ukázala na problém s webem fotogalerie. Tu využívám již opravdu dlouho. Systém jsem si upravil dle vlastních potřeb a nahrávám tam všechny fotky, které na internetu publikuji. Za normálních okolností však návštěvnost této galerie nepřesahuje pár desítek unikátních návštěvníku a tak mi zátěž nedávala smysl. Podle google analytics dokonce v problematických dnech bylo na galerii minimum lidí a přesto zátěž serveru neustala. Bylo na čase podívat se tedy do logu webového serveru, ve kterém jsou uchovávaný všechny požadavky na spojení se serverem a ten tedy mohl poskytnou odpověď na to, co se na téměř nepoužívané fotogalerii děje.

Po otevření logu jsem ale narazil na další překážku. Tou byla samotná velikost souboru s logem. Soubor měl přes 50 000 řádku za dva dny. Analýza takového množství dat není ani rychlá ani jednoduchá. Jak bylo na první pohled jasně vidět problém, byl v návštěvnosti indexovacími roboty, kteří neustále galerii i všechny jejich podstránky navštěvovali. Abych si však udělal představu, jak velké jsou požadavky na zobrazení stránek právě roboty, musel jsem data nějak roztřídit. Hledal jsem tedy nějaký program, pomocí kterého by bylo možné data nějak roztřídit. Narazil jsem na pár zajímavých, ale placených programu ale, protože jsem měl server pod zátěží a nechtěl jsem dávat peníze za program, jehož využití je jen nárazové, rozhodl jsem se data si roztřídit a zanalyzovat sám.

Přenesl jsem si log přístupu ze serveru a na svém notebooku jsem si připravil databázi, abych mohl pomocí PHP data ze souboru roztřídit a poté vložit do databáze. Normálně pro PHP nepoužívám čtení ani zápis ze souborů a tak jsem hledal možnost, jak celý systém vlastně postavit. Nejhorší byla část z odmazáváním zpracovaných řádků ze souboru, se kterou mi nakonec pomohl kolega. Za nedlouho jsem tedy měl databázi i skript, který z log souboru vytahoval a analyzoval řádky a ukládal jejich obsah do databáze.

Nijak jsem si nehrál z rozhraním ani s optimalizací, cílem bylo vzít počet řádků, každý rozdělit na požadované položky posléze ověřit, jestli stejný záznam v databázi již není a pokud ne, tak jej do databáze uložit. Poté všechny analyzované řádky ze souboru s logem odmazat. A to celé opakovat dokud v souboru jsou nějaké řádky. Ochranu a ověření jsem přidal právě proto, že kdyby se skript nestihl zpracovat, abych jej mohl ověřit znovu a přitom nedocházelo k chybám s počtem dat. Ze začátku vše fungovalo docela obstojně, ovšem, čím větší databázi jsem již měl, tím delší čas potřeboval skript na ověření nových záznamu. Ukázalo se, že limitujícím faktorem byl disk, který se při běhu analýzy docela zapotil. Zpracovat několik logu o velikostech 20 mb plných dat, tedy notebooku zabralo docela dost času.

Po několikahodinovém importu jsme měl konečně všechny data v databázi a mohl jsem s němi dělat selekce a počítat dle svého vlastního uvážení. Hned prvním seřazení jsem zjistil, že i když web fotogalerie měl minimální návštěvnost a tedy dle prvního pohledu i minimální důvod server zatěžovat, byly jeho stránky zobrazováni nejvíce krát.

Počet zobrazení stránek byl téměř více jak 5× větší než stránka, na kterou chodí denně desítky lidí a zobrazují spousty podstránek.

Díky datu v databázi jsem však všechny data mohl libovolně třídit i spojovat a tak jsem si napsal druhou stránku, díky níž jsem si nejprve zobrazil požadavky jen pro fotogalerii a poté jsem spojil data podle hlavičky prohlížečů, kteří o stránku zažádaly. A výsledek byl prokazatelný a utvrzoval mě jen v tom, co jsem celou dobu tak nějak tušil. Server zpomalovaly požadavky indexovacích robotu, kteří během 2 dní fotogalerii navštívili více jak 53 000×. Přitom se dle mého nejednalo vyloženě o přínosné roboty typu Google, bing či seznam, kteří na oplátku přivádějí návštěvníky, ale pro mě naprosto neznáme názvy. Zarážející bylo i počet stránek, na které se vydali. Například první robot navštívil a zobrazil více jak 24 000 stránek. Zatím co robot od Google si vyžádal pouze 121 stran. Neznámý robot si tak zobrazil data, které by vyžádal Google s téměř 200 roboty.

Rozhodl jsem se pro blokaci všech tří hlavních robotů, pomocí souborů robot.txt v hlavním adresáři fotogalerie. Za normálních okolností bych se pokusil roboty pouze zpomalit, nicméně neznámá jména systému, ale také vědomí, že vlastní fotogalerii vlastně indexovat tolik nepotřebuji, mě přivedlo na myšlenku robotům toto nenažrané indexování zakázat. Z prvních analýz je vidět, že i když mají roboti nastaveno, aby se dívali do souboru, který jim říká zda a co mohou indexovat, někteří to si s tímto nastavením hlavu nelámou. Teď již ale mám nástroj, jak relativně jednoduše zjistit, kdo na web chodí a pokud si nenažranci na indexaci nedají říct přístup k webům jim prostě na základě jejich IP adresy zakážu. Vždy jsem indexovací roboty bral jako součást webové návštěvnosti a jako nutnost, abych mohl být ve vyhledávačích to, že by mě tyto systém vytěžoval procesor na 100% téměř třikrát do minuty, jsem ovšem nějak nepředpokládal.