Úzké hrdlo (anglicky Bottleneck) je stav kdy rychlost aplikace z důvodu nějaké komponenty či části skriptu začne být znatelně limitována. U WordPress se s efektem úzkého hrdla setkáte dříve či později. Jeden den vám půjde velice rychle a druhý zničehonic začne drhnout. Chvilkami se načítá pomalu, někdy může dojít až do timeout popřípadě se objeví 503. O pár minut později už vše šlape jako by se nic nedělo. Bez monitoringu se o něm ani nemusíte dozvědět.

Obecně bychom mohli říct, že úzkým hrdlem je téměř vždy plugin anebo šablona. Některé jejich části mohou navzájem mezi sebou být nekompatibilní anebo za určitých okolností omezit přímo WordPress. Je třeba si uvědomit, že autoři pluginů a šablon nemají reálnou šanci otestovat všechno se vším. Občas vývojáři testy i podcení a vsází na zpětnou vazbu uživatelů. Proto je také nutno případné problémy hlásit tvůrcům.

Databáze

Hodně zákeřné jsou tabulky v databázích. Problém může ale i nemusí způsobit objem dat, počet záznamů, nevhodně navržená struktura a samozřejmě i SQL dotazy přímo ve skriptu.

Samotná zákeřnost pak může být například v SQL dotazu, který pracuje s více tabulkami. U pár set záznamů je zpomalení takřka nepostřehnutelné, ale jakmile se počet záznamů přehoupne přes tisíc tak už jde do vteřin.

Pokud máte podezření na databázi je nutné udělat analýzu všech dotazů. K tomu použijte plugin Query Monitor. Jak se s ním pracuje jsme si ukázali v příkladu Praktická ukázka: Pomalá administrace WordPress.

Tím zjistíte, které SQL dotazy jsou pomalé, tedy jsou vašim úzkým hrdlem. Následně je třeba zjistit proč jsou vlastně pomalé. Může se jednat o velké množství nepotřebných duplicitních záznamů, poškozenou tabulku, chybějící indexy, ale i nevhodné slučování tabulek atd.

Komunikace s třetí stranou

Na rozdíl od databází, kdy je problém většinou trvalý, je problémová komunikace se serverem třetí strany nárazovou záležitostí. Například když plugin ve vašem WordPress začne volat domů přesně v 7:00, aby si stáhl aktuální přehled novinek, a nedovolá se. Pokud tato situace není ošetřena, a dejme tomu timeout PHP je 120 vteřin, tak od 7:00 do 7:02 je váš WordPress nedostupný. Prostě váš web nefunguje od 7:00 do 7:02. Kde vás napadne že by mohla být chyba? Samozřejmě výpadek hostingu. Jenomže už letmé prohlédnutí error.log vám ukáže že v tomto času byl problém se skriptem.

WordPress, pluginy a šablony se pokouší někam spojovat prakticky pořád. Většinou se využívá nějaké API a komunikace je dobře ošetřena. Takže případné chyby neovlivní samotnou webovou prezentaci. Ovšem třeba Nástěnka WordPress je právě komunikací se servery třetích stran zpomalována nejčastěji. Pokud máte pomalou Nástěnku tak 4 z 5 případů to je kvůli stahování dat odjinud.

Jenomže na rozdíl od databáze je hledání úzkého hrdla u komunikace poměrně náročnější. Napříkald u příkladu na začátku byste museli monitorovat právě komunikaci kolem sedmé hodiny, což může být náročnější. A to i výkonově. Základem tedy bude prevence a občas projít error.log.

Na dohledání konkrétního problému v rámci komunikace s třetí stranou používám plugin Snitch. Práci s ním jsme si představili v článku Jak najít problémové pluginy, které komunikují s jiným serverem a zpomalují WordPress. Ovšem ne všem vyhovuje. Někdo doporučuje spíše P3 (Plugin Performance Profiler). Navíc pokud umíte anglicky najdete k němu i více tutoriálů. Osobně ale na Snitch nedám dopustit.

Jinak nezapomeňte, že když zjistíte co má problém s komunikací nemusíte zjistit, proč to má problém komunikovat. Ne vždy je na vině plugin. Některé české webhostingy omezují komunikaci mezi servery z bezpečnostních důvodů.

Pomalý disk a množství souborů

Zatímco pro databázi není žádný problém 10 tisíc záznamů v jedné tabulce, tak 10 tisíc souborů v jednom adresáři už se projeví. S tímto problémem jsem se u WordPress už tak dva roky nesetkal, ale stojí za to jej připomenout, protože si vývojáři počet souborů v adresáři hlídají.

Jednoduše řečeno, pokud z nějakého důvodu vytvoří skript v jednom adresáři více jak tisíc souborů, tak je zaděláno na problém. Správně by měl rozdělit soubory do podadresářů, aby se hlídalo alespoň těch max 1K souborů/adresář. Tohle není nějaké univerzální číslo. Nikdo přesně neřekne kolik už je moc souborů v adresáři, ale já to tak mám kvůli zkušenostem ze sdílených webhostingů ze zahraničí, kdy při 1024 souborů už blokovali zápisy do adresářů, protože jim to přetěžovalo servery.

Tedy velké množství souborů v adresářů zpomaluje WordPress a je třeba se tomu vyhnout za každou cenu. Tento problém dělaly hlavně cachovací pluginy, které při větším množství stránek vše nacpaly do jednoho adresáře. Teoreticky by se to mohlo opakovat, pokud by byly špatně nastaveny práva a skript by nemohl po sobě mazat stará data.

Popravdě po přechodu na SSD už problém zápisu/čtení tak nějak zapadl, ale stále se hojně používají HDD. Ne všude máte SSD, takže četné čtení a zapisování do adresářů by mohlo zpomalit instalaci. Ovšem tohle se bez přístupu k serveru špatně monitoruje.

O problému je však dobré vědět.

Závěr

Tohle jsou nejčastější úzké hrdla u WordPress, která jsem kdy řešil. Samozřejmě mohou tu být i chyby a smyčky ve skriptech, ale to si necháme na jindy. To je rozsáhlejší téma a spíše na tutorial 🙂

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInBuffer this page