Efektivita fungování webových aplikací

Stejně jako v loňském článku Bezpečnost práce s webovými aplikacemi bychom se s vámi rádi podělili o naše zkušenosti z provozování webhostingových služeb, tentokrát z oblasti efektivity a optimalizace běhu webových aplikací. Občas s uživateli našich služeb řešíme problémové situace, které vyplývají z nedostatečně kvalitního návrhu a programového řešení jejich webových aplikací. Tyto situace se obvykle objevují při vyšší návštěvnosti daného webu a mohou vést k různým problémům od pomalého načítání stránek až po přetěžování serverů.

Webovou aplikací v tomto článku budeme chápat webové stránky, pro jejichž sestavení je využíván skriptovací jazyk (u nás typicky PHP), a která využívá pro ukládání dat databázový systém (u nás nejčastěji MySQL). Na našem sdíleném hostingu je běh webové aplikace obvykle rozdělen na dva různé servery - webový server, který zajišťuje vykonávání skriptů a prezentaci statického obsahu, a databázový server, na němž běží databáze. Efektivitu fungování webové aplikace je tedy třeba hodnotit na těchto dvou místech a pak při vzájemné komunikaci mezi nimi. Na vyhrazeném hostingu (tedy na virtuálních nebo dedikovaných serverech) všechny operace nejčastěji zajišťuje pouze jeden server (webserver a databázový server běží na jednom stroji).

V následujícím textu upozorníme na oblasti, ze kterých mohou plynout problémy, a na možné chyby v návrhu a realizaci webových aplikací, s nimiž se setkáváme. Zároveň se také pokusíme naznačit řešení daných problémů.

Webserver

Efektivita skriptů

Do této oblasti patří kvalita programového kódu aplikace. Při hodnocení efektivity skriptů je třeba například sledovat, jestli aplikace nevykonává nějaké zbytečné operace (třeba opakované výpočty, zbytečné dotazy do databáze, opakované načítání souborů...), zda optimálně využívá přidělenou operační paměť, zda nevyužívá zastaralé (a pomalé) funkce či postupy apod. Právě v této oblasti může vznikat nejvíce problémů různých typů a jejich odstranění může přinést znatelná zlepšení.

Požadavky na webserver

Při velké návštěvnosti webu (a tedy velkém počtu požadavků na webserver) je pro plynulý chod aplikace třeba zajistit, aby zpracování požadavků bylo co nejjednodušší a tím pádem rychlé. Čili statický obsah by měl být skutečně prezentován staticky (v rozporu s tím je například posílání obrázků pomocí PHP skriptu, což může být problematické i z jiného důvodu - viz článek Volání lokálních souborů externě) a sestavení dynamického obsahu by mělo být pro aplikaci co nejsnadnější. Tomu může pomoci například cachování (tedy "předgenerování") obsahu, které je vhodné například i pro snížení počtu požadavků do databáze (tomu se budeme věnovat dále v odstavci o databázích).

Přepisovací pravidla (mod_rewrite)

Nevhodná pravidla pro mod_rewrite mohou zpomalovat zpracování požadavku na webserveru. Nevhodnými jsou taková pravidla, která jsou zbytečně složitá, rozsáhlá, mohou vést k zacyklování, nedostatečně ošetřují chybové stavy apod.

Používání .htaccess

Používání .htaccess je provozně poměrně náročná záležitost, zpomaluje výkon webserveru cca o 20%. Proto .htaccess doporučujeme používat pouze v případech, kdy je to opravdu nutné (například pokud je třeba často provádět změny pravidel pro mod_rewrite). Alternativou k používání .htaccess je nastavení přímo v konfiguračním souboru domény (VirtualHostu). Některá nastavení jsou prováděna automaticky (z klientské sekce), jiná provedou na požádání naši administrátoři. Toto řešení sice může být méně flexibilní, nicméně negativně neovlivňuje výkonnost aplikace. Bližší informace o .htaccess a mod_rewrite případně najdete v naší nápovědě na stránce .htaccess, mod_rewrite.

Počet souborů

Na rychlost zpracování požadavku webserverem může mít vliv i množství souborů umístěných v jednom adresáři. Se zvyšujícím se počtem souborů v adresáři (v řádech stovek a tisíců) samozřejmě klesá rychlost práce s nimi. Proto je vhodné soubory rozdělovat do různých podadresářů. Nepotřebné soubory (například staré dočasné soubory) by samozřejmě měly být ze serveru průběžně odstraňovány. Stejně tak se na rychlosti zpracování požadavku může negativně projevit velké množství souborů, které aplikace potřebuje pro sestavení stránky načíst. Zde platí, že by měly být načítány pouze opravdu potřebné soubory a v rozumném množství.

Načítání dat z externích zdrojů

Webové aplikace někdy pracují s externími datovými zdroji (například RSS, různá API, kurzy měn apod.). V takových případech je třeba dobře podchytit situace, kdy má například externí zdroj horší odezvu, nebo dokonce vůbec není dostupný. Pokud to logika fungování aplikace dovoluje, je vhodné data z externích zdrojů nenačítat při každém požadavku, ale využívat cachování. Pro automatické pravidelné zpracování externích dat je vhodné například využití cronu.

Databáze

Počet dotazů

Zpracování každého požadavku na databázi zabere nějaký čas (čas na obsluhu spojení - tedy posílání dat po síti a čas na samotné zpracování dotazu databázovým serverem). Tyto časy se sice obvykle pohybují na úrovni setin či desetin sekundy, nicméně je-li dotazů pro sestavení stránky potřeba velké množství, samozřejmě to může výrazně prodloužit dobu vykonávání skriptů. Proto je třeba minimalizovat počet požadavků (dotazů) do databáze potřebných pro získání požadovaných dat. Nicméně ne vždy musí být minimální počet dotazů optimálním řešením (u náročných dotazů - viz dále).

Složitost dotazů

U složitějších dotazů (například dotazů pracujících s více tabulkami, vnořených dotazů apod.) je třeba očekávat delší dobu potřebnou na jejich vykonání. Takové dotazy by měly být ve webových aplikacích, kde je požadována rychlá odezva, spouštěny co možná nejméně. Někdy může být efektivnější provést více jednodušších dotazů, než jeden složitý. Na rychlosti vykonání dotazu také nepřidá použití klauzule SELECT * - server musí v tomto případě nejdříve zjistit, jaké sloupce daná tabulka má a až pak může vybírat záznamy. Proto je lepší rovnou specifikovat jména požadovaných sloupců.

Data

Se vzrůstajícím počtem záznamů a objemem dat se samozřejmě prodlužuje doba nutná k provedení dotazu. V databázi by proto měla být pouze data, se kterými se aktivně pracuje a která v databázi být musejí z logiky fungování aplikace. Například neměnné texty na webových stránkách je lepší umístit do souborů na webserveru, než do databáze - odpadne tak nutnost stále stejné texty při každém načtení stránky přenášet z databáze.

Indexy

Databázové indexy slouží k urychlení dotazování, vytvářejí pomocnou strukturu v operační paměti databázového serveru s odkazy na konkrétní záznamy v tabulkách (něco jako například rejstřík v knize). Zejména při práci s větším množstvím záznamů může vhodné použití indexů zrychlit dotazování velmi výrazně. Proto je správné definování indexů u každé tabulky velmi důležité.

Zamykání tabulek

Při operacích měnících obsah (INSERT, UPDATE, DELETE) jsou databázové tabulky pro jiné procesy uzamčeny. Také k tomu může docházet při používání transakcí. Ostatní procesy čekají na dokončení dané operace a uvolnění zámku a až poté mohou s tabulkou (či záznamem) pracovat. S tím je třeba počítat při práci s tabulkami, na nichž se často provádějí tyto operace a je to také důvod, proč by databáze neměla být používána například pro logování přístupů. Tabulka, do níž jsou přístupy logovány, je totiž často zamčena a při větším počtu současných návštěvníků na daném webu to může vést k prodlevám v načítání stránek právě kvůli čekání na uvolňování těchto zámků.

Závěrem

Efektivitě fungování webových aplikací se věnuje celá řada odborných publikací a článků, a to lépe a hlouběji, než tento text. Konkrétnější technické informace proto doporučujeme hledat tam. Bohužel autoři webových aplikací s nimi často nejsou seznámeni. Cílem tohoto článku je na jednom místě upozornit na problémy, se kterými se v naší praxi setkáváme. Samozřejmě, ne každé použití některé z výše uvedených záležitostí musí být problematické. Stejně tak nemusí být v každém případě možné problémovou část upravit, neboť dané řešení vyžaduje logika aplikace. Nicméně při vývoji aplikace je třeba stále zvažovat, jak provozně náročná daná operace a postup je. A v případě velkých provozních nároků zvolit adekvátní hostingové zajištění - například vyhrazeným serverem (viz. předchozí článek Spolehlivé servery).

Velmi uvítáme Vaše připomínky a doplnění k tomuto článku. Můžete je uvést zde v komentářích, nebo je pošlete na zákaznickou podporu. Článek pak případně budeme dále rozšiřovat.