Problémy s webovými aplikacemi

Pokud se při načtení Vašeho webu zobrazí jen prázdná bílá stránka, nebo chybové hlášení "na webu došlo k závažné chybě" je příčinou zřejmě nějaká chyba v PHP skriptu, který tuto stránku vygeneroval. Může se jednat například o překlep, chybný kód, volání nepovolené funkce nebo třeba chybějící soubor. PHP může chybu konkretizovat buď výpisem na web, nebo uložením do logu chyb. Ve výchozím stavu je vypisování i logování PHP chyb vypnuto. Pro účel odhalení chyby je možné vypisování či logování PHP chyb zapnout, nastavení provedete v klientské sekci. Veřejné vypisování chyb může představovat bezpečnostní problém, proto by mělo být povoleno jen dočasně.

Situace, kdy je požadavek na web vrácena chybová stránka s HTTP kódem 500 (Internal Server Error), může mít dvě skupiny příčin. Tou první je neplatná nebo nepovolená direktiva v souboru .htaccess. Řešením je v tomto případě oprava nebo odstranění dané direktivy. Druhý důvodem může být nějaká chyba při běhu PHP skriptu. Může se jednat třeba o vyčerpání nějakého limitu, nebo chybu při komunikaci s databází. K odhalení konkrétní chyby by opět mělo pomoct zapnutí vypisování nebo logování PHP chyb.

Webserver vrací na požadavky chybovou stránku 503 (Service unavailable) v případě, že je dosažen limit počtu současně spuštěných PHP procesů pro danou doménu, nebo celý webserver. Na sdíleném webhostingu je tento limit dán pevně a není možné jej měnit, na managed serverech je vypočítáván dynamicky. Následující informace se týkají především právě managed serverů. Mechanismus fungování a výpočtu příslušných limitů je popsán v článku Kolik domén mohu na serveru provozovat?. Tato situace naznačuje, že server v danou chvíli nemá dostatek prostředků pro zajištění aktuálního provozu současných aplikací. Příčinou může být například příliš velký počet provozovaných aplikací na serveru, nebo jejich velká provozní náročnost, způsobená buď vysokými výpočetními nároky, nebo velkou návštěvností. Může se také jednat o důsledek dlouhého čekání na nějaké operace při nevhodném řešení aplikace.

Jak situaci řešit?

Pokud se jedná jen o výjimečnou špičku, problém se po čase obvykle vyřeší sám, až zvýšený provoz opadne. Každopádně dlouhodobým řešením a prevencí je buď zajistit serveru více systémových prostředků, nebo mu umožnit současné prostředky využívat efektivněji. Jsou v zásadě tři možné přístupy, lepších výsledků je možné dosáhnout jejich kombinací.

• Navýšení výkonu serveru
  Obvykle nejjednodušším řešením je navýšení velikosti operační paměti (RAM) serveru a nejlépe i počtu procesorů (protože zvýšený počet běžících PHP procesů bude vyžadovat i větší výpočetní výkon). U virtuálních serverů se jedná o velmi jednoduchou operaci (vyžaduje pouze krátkou odstávku serveru v řádu několika minut), kterou provedeme na požádání. Nicméně ne vždy se jedná o nejvhodnější řešení.
• Snížení provozní náročnosti aplikací
  Snížení výpočetní a paměťové náročnosti jednotlivých PHP procesů serveru umožní jich ve stejném čase obsloužit více, a také jich spouštět více současně. Informace a tipy k tomuto tématu najdete v článku Efektivita fungování webových aplikací. Do tohoto bodu patří i vylepšení aplikace směrem k eliminaci dlouhého čekání na dokončení nějakých operací (např. na uvolnění zámku sezení nebo zámku v databázi, či při nedostupnosti vzdáleného zdroje, s nímž aplikace pracuje).
• Snížení počtu aplikací na serveru
  Řešením také může být některé aplikace ze serveru přesunout jinam - například jiný nově zřízený server. Díky tomu se uvolní část systémových prostředků, které budou moct využít stávající aplikace.

Jak identifikovat problémové aplikace?

Problémové aplikace jsou obvykle ty výpočetně nejvíce náročné, nebo nejvíce navštěvované (tzn. pro jejich fungování je potřeba spouštět nejvíce PHP procesů). Přehled o návštěvnosti jednotlivých webů můžete získat například ze statistik přístupů AWStats, přehled o celkové návštěvnosti na serveru pak z hodinových statistik Analog dostupných v klientské sekci, ve správě daného serveru v záložce Statistiky.

K identifikaci provozní náročnosti jednotlivých aplikací může pomoct výpis aktuálně běžících PHP procesů na serveru dostupný v klientské sekci, ve správě daného serveru v záložce Provoz a služby. Zde můžete sledovat aktuální limity, počet procesů k jednotlivým doménám, běžící crony, a také jejich paměťovou náročnost a čas, po který využívaly procesory. Za potencionálně problémové je možné považovat aplikace s velkým počtem spuštěných procesů (ve stavu běžící), velkou paměťovou náročností a velkým procesorovým časem.

Na rychlost načítání webových stránek má vliv celá řada faktorů. Pomineme ty externí, jako např. rychlost a kvalita internetového připojení uživatelů, které jsou z pohledu provozovatele webu neovlivnitelné. Také nebudeme řešit věci týkající se statické části webové prezentace (tj. například počet a velikost obrázků na stránce, javascripty apod.). Soustředíme se na rychlost načítání stránek s ohledem na vykonávání skriptů na serveru, tedy PHP kódu a případné práci s databází, což jsou nejčastěji problematická místa. Jsou dvě možné příčiny dlouhého vykonávání programového kódu pro sestavení stránky a tím i jejího pomalého načítání - buď velká výpočetní náročnost Vaší aplikace, nebo nedostatečný aktuální výkon Vašeho serveru.

Výpočetní náročnost aplikace

Vykonání každé operace (např. načtení souboru, dotaz do databáze, matematický výpočet apod.), kterou Vaše aplikace provádí při sestavování stránky, vždy vyžaduje nějaký čas. Teprve po vykonání všech potřebných operací je výsledná stránka odeslána do prohlížeče uživatele. Pokud je těchto operací velké množství, nebo jsou některé z nich časově náročnější (typicky práce s databází), pak samozřejmě i sestavení stránky pro uživatele trvá delší dobu. Zkrácení tohoto času je možné dosáhnout optimalizací a zefektivnění kódu Vaší aplikace. Informace a tipy k tomuto tématu najdete v článku Efektivita fungování webových aplikací.

Výkon serveru

Příčinou pomalého načítání stránek může být také aktuální vysoká zátěž na webserveru, na kterém jsou tyto stránky provozovány. Zpracovávání jednotlivých požadavků a výpočetních operací proto trvá déle, což se projevuje na delším načítání stránek. Může se jednat o problém dočasný, který po čase sám odezní (např. špička návštěvnosti, návštěva vyhledávacího robota), nebo jej vyřeší naši administrátoři (útok). Může se ale jednat i o situaci trvalou, zapříčiněnou tím, že Váš server aktuálně nemá dostatek výkonu pro provozovaní Vašich aplikací v jejich současné podobě. Možná řešení v tomto případě jsou popsána v článku týkajícím se chyby 503.

Pro běh PHP procesů jsou na webserveru nastavena dvě časová omezení, která zabraňují nekontrolovanému běhu procesů, vyčerpání limitu maximálního počtu současně spuštěných procesů, nebo přetížení serveru. Na obvyklý provoz a generování běžných webových stránek nemají žádný vliv, uplatňovat se ale mohou při některých specifických časově náročných úlohách, jako jsou například importy či exporty větších objemů dat.

Prvním z těchto omezení je nastavení PHP max_execution_time. To je možné do určité míry měnit v klientské sekci, v případě dosažení tohoto limitu je vykonávání skriptu ukončeno fatální PHP chybou. Druhým je časový limit mechanismu fcgid, který zajišťuje spouštění PHP procesů. V případě jeho dosažení je vykonávání skriptu ukončeno chybou serveru 500 (Internal Server Error). Na vyhrazených hostingových službách můžeme tento limit v případě nutnosti na požádání změnit.

Virtuální servery bez vyhrazené IP adresy mají další časový limit, který může u dlouho zpracovávaného požadavku znemožnit korektní zobrazení výstupu. Jedná se o časový limit proxy serveru pro vrácení obsahu. Ten je nastaven na 240 sekund a není možné jej individuálně měnit. V případě, že proxy server do uvedené doby nedostane od webserveru žádnou odpověď (tj. vygenerovanou stránku), vrátí chybu 504 (Gateway Timeout).

Nedostatečná bezpečnost práce s hostingovými službami nebo nedostatečná bezpečnost uživatelské PHP aplikace může útočníkovi umožnit data aplikace pozměnit a hostingové služby pak zneužívat (nejčastěji k rozesílání spamu, šíření škodlivého software, nebo vzdáleným útokům). Toto téma blíže rozebíráme ve starším, ale stále aktuálním článku Bezpečnost práce s webovými aplikacemi.

Jedná se o velmi závažný problém, který je potřeba neprodleně řešit odstavením aplikace z provozu (aby se zabránilo vzniku dalších škod), odstraněním škodlivého kódu, který útočník vytvořil, a zabezpečením chyby, která vznik problému umožnila (tj. typicky oprava bezpečnostní chyby v aplikaci, nebo používání bezpečného způsobu práce se službami). Druhý krok je individuální věcí dané aplikace či práce daného uživatele, detailněji se ale podíváme na to, jak v aplikaci identifikovat škodlivý kód, což je předpokladem jeho odstranění.

Vyhledání a odstranění škodlivého kódu z aplikace by měl v ideálním případě provést její autor, který aplikaci zná, a ví, co je a co není její součástí. Nově vytvořené nebo pozměněné soubory je možné snadno najít podle data poslední změny. Odhalení škodlivého kódu je pak věcí prozkoumání zdrojových kódů v jednotlivých souborech. Pro vykonání škodlivého kódu se nejčastěji používá funkce eval. Snahou útočníků je svůj kód maskovat s cílem co nejvíce ztížit jeho odhalení a opravu aplikace. Škodlivý kód proto obvykle není ve skriptech uveden přímo, ale je nějakým způsobem zakódován. Aby mohl být spuštěn, je třeba jej nejdříve rozkódovat. Dalším náznakem tedy může být přítomnost dekódovacích funkcí, například base64_decode, nebo gzinflate.

Nejjednodušší cestou k nalezení a odstranění škodlivého kódu z aplikace tedy může být vyhledání nově změněných souborů obsahujících zmíněné funkce (často jsou používány ve vzájemné kombinaci), a tyto soubory vymazat či upravit. Nicméně použití uvedených funkcí nemusí být vždy škodlivé, jsou (pro jiné účely) v aplikacích využívány celkem běžně. Stejně tak se nemusí jednat o jediný způsob vykonání škodlivého kódu. Je jich celá řada, jsou popsány například v článku Jednoduché PHP backdoory na serveru soom.cz. K nalezení souborů obsahujících podezřelý kód může také pomoci funkce Kontrola kódu aplikací, která je (na serverech s PHP 5.4 a novějším) k dispozici v klientské sekci, ve správě příslušné domény v záložce Webserver.