Po migraci FeedIT.cz na vlastní WordPress u BlueBoardu (z WordPress.com) se objevil problém s nestíháním. Ten web má přes 55 tisíc příspěvků, takže i když nemá nijak zásadní návštěvnost (okolo jednoho tisíce návštěv ve všední dny), tak je to přece jenom něco trochu většího.
Cache je nutné, ale pozor
Hlavní problém se objevoval ráno, při prvním vložení nového příspěvků. Skončilo to 50x chybou a trvalo asi pět minut, než byl web opět dostupný. Článek se přitom vložil správně, ale cokoliv dalšího už poté nebylo možné. Podezíral jsem generování sitemap.xml a WP Fastest Cache a nakonec se ukázalo, že to druhé je původcem – stačilo vypnout automatické mazání kompletního cache při vložení nového článku (je tam ještě totéž při opravě článku).
WP Fastest Cache tvrdil, že jde jen o mazání konkrétního článku a hlavní stránky (pokud tam ten článek patří), ale buď tam mají chybu nebo to není pravda – vypadá to, že se vydají mazat kompletní cache. Což u takto rozsáhlého webu trvá dlouho.
Vypnout nakonec můžete i ono mazání při aktualizaci a můžete to dělat ručně (na příslušné stránce a na hlavní stránce). Případně zkusit jiný cache, nebo klasicky počkat, jestli to náhodou neopraví (což se mimochodem o pár týdnů později stalo).
Pokud na svém WordPressu nemáte žádný cache, tak je to dost dobrý důvod k nestíhání a měli byste to řešit.
O pár měsíců později WP Fastest Cache šlo pryč a nahradilo ho WP Super Cache. To se ukázalo jako rychlejší a méně náročné na počty souborů. Případně viz Jaké cache použít pro váš WordPress web?
Sitemap.xml a indexace webu
Se Sitemap.xml to ale mohlo souviset také, navíc se v tomto případě projevuje jako problém i jinde. All In One SEO totiž generuje Sitemap.xml kompletního webu, dokonce včetně štítků, rubrik, médií a dalších taxonomií. Je tedy pochopitelně obrovská (FeedIT.cz má přes 4 000 štítků). Při hledání příčiny jsem objevil, že se na zmigrovaný web vrhla Monitora.cz a kompletně ho stahovala – ukázalo se, že mají chybu v robotu a prostě znovu natáhli vše co je Sitemap.xml (i proto, že na WordPress.com tam není všechno).
Řešením v tomto případě je jiný plugin, co nevytváří kompletní Sitemap.xml. A velmi pravděpodobně se touto cestou vydám. Pár tipů na jiné viz Jak na WordPressu vytvořit Sitemapu? Nejlepší pluginy pro sitemap.xml
Při řešení nestíhajícího WordPressu je třeba se dívat i na to, co se vlastně na webu děje. Protože pokud se na vás vrhlo několik robotů, tak může jít o značnou zátěž, která může chod webu velmi ovlivnit. Ono “dívat se“ bude trochu komplikované, protože na většina hostingů nebudete mít možnost se dívat na http logy, ani sledovat zátěž databáze, natož mít něco pro kontrolu v reálném čase. Ochota technické podpory navíc bývá velmi různorodá.
Zkoumáním statistik návštěvnosti (Blueboard je vytváří z logů serveru) se navíc ukázalo, že podobným způsobem se na web vydal AHREFs (mám ho tam založený pro analýzy) a nevypadá to, že by zrovna dodržovali nastavení že mají použít jen jedno vlákno a dvě sekundy mezi požadavky. AHREFs jsem nakonec vypnul, byť byl nastavený “jednou za měsíc”. Až budu případně potřebovat, tak ho je možné pustit ručně.
Zatěžující SQL dotazy
Časté nestíhání je ale vinou přímo šablony nebo některého z pluginů – zejména tam, kde dochází k častým a náročným SQL dotazům. Jednu šablonu jsem z tohoto důvodu nakonec musel vyměnit za jinou, tvůrci volali funkci WordPressu zpracovávající a vracející prakticky kompletní obsah meta tabulky při každém vyžádání obrázku (média).
Blueboard má hodně povedenou funkci – v administraci je u SQL serveru možné se podívat ne nejdéle trvající dotazy. Hodně to může pomoci, protože odhalit místo kde se děje něco nepravého je obtížné – Existuje plugin Query Monitor coby fantastická pomůcka, ale musíte vědět kde hledat – ne vždy se totiž nepravosti dějí v tom na co pravidelně vstupujete.
Pomalé SQL dotazy pak navíc musíte najít ve zdrojových kódech (WordPressu, šablony, pluginů) a není to až tak triviální – většinou se tam sestavují postupně a hledání je tak trochu detektivní práce.
Pluginy a widgety, ale i šablona
Při hledání pomůže i tak prostá věc jako vypínat konkrétní pluginy (co nejsou bezpodmínečně nutné pro běh webu) a sledovat zda to povede ke změně chování.
Jak už zaznělo, problém může být i v samotné šabloně – tady pomůže přepnout na některou z výchozích od WordPressu (ty co jsou označené číslem roku ve kterém byly vytvořeny). Jsou velmi jednoduché, čisté a rychlé.
Vyšší zátěž hledejte i ve Widgetech – čím víc jich nasekáte na stránkách, tím větší dopad to může mít. Související články (Jak na související články (příspěvky) na WordPressu) bývají velký žrout, ale i nejčtenější a podobné věci. Zkoušejte je odstranit jeden po druhém a sledovat jak se to projeví.
Určitou dobu po čerstvém zprovoznění (ale hlavně po migraci) je větší zátěž běžná – některé pluginy například kontrolují bezpečnost a postupně procházejí vše co na webu máte. Možná jste si tam dali něco pro kontrolu nefunkčních odkazů. Migrace mohla přinést velké množství 404 a jakkoliv máte jistě Redirection pro hlídání, může to být také důvodem vyšší zátěže.
Pozor při změně šablony ale i změně pluginů na kombinace s cache – měli byste ho promazat, protože tam mohou být staré verze stránek, které přes JavaScript mohou stahovat či aktivovat něco, co už na webu nemáte.
PHP Error Log a HTTP Logy
Další dobrý pomocník bývá PHP Error Log (a zapnuté logování) a HTTP logy – jak klasický záznam o přístupu tak záznam o chybách http serveru. Ne vždy je ale budete moci mít, některé hostingy je neposkytují, některé ano, jiné si za to řeknou extra peníze.
PHP Error Log je poměrně snadný na kontrolu – většinou tam u problematického webu najdete přečerpání dostupné paměti, ale mohou tam být i jiné zádrhele. Http logy už mohou být složitější, pro velké weby může jít o zásadně velké soubory – naučte se v nich hledat, ale určitě pomůže si i opatřit nějaké analyzátory http logů (pokud je přímo nemá váš hosting).
Otravné a časté dotazy odněkud zvenčí
Při zkoumání můžete zjistit i to, že důvodem velké zátěže je něco/někdo s velmi častým dotazováním. Může stahovat příliš často RSS, “monitorovat” nějakou stránku či více stránek, stahovat něco náročného (velkého nebo s zátěží SQL).
Tady potřebujete zjistit IP adresu a buď se pokusit vlastníka kontaktovat (často spíš nemožné) nebo prostě této IP adrese zakázat přístup na server. Často to bývají roboti, indexátory (jiné než Google, Bing či Seznam), analyzátory a různé bezpečnostně otravné věci – velmi často boty co se snaží o brute force přístup či masové vkládání komentářů.
Příčiny mimo vaši kontrolu
Příčinou pomalého serveru ale může být i váš poskytovatel hostingu. Proto je dobré vědět kde váš hosting má “status dashboard” – a než začnete panikařit, tak se tam podívat. Případně se podívat zda “nefunkční” či pomalé je i něco jiného, než jenom právě ten váš web. Můžete pak kontaktovat technickou podporu a ověřit si, že je možná problém “u nich”.
Mezní případ je ten, že jde o DDoS útok, mířící možná na vás, možná na vašeho poskytovatele hostingu.
Další tipy týkající se WordPressu
-
Problémy, problémy a jenom problémy. S fonty ….
„Ahoj, v Chrome OS je nějaký problém s písmem, “ napsal Janek Wagner a s ním ještě pár dalších lidí, včetně těch an Twitteru a Facebooku. Jasně, české znaky se v šabloně…
-
365 tipů. Co jeden den, to jeden tip. A spousta věci k vyzkoušení
Ne že bych neměl co dělat, ale prostě občas chcete něco zkusit. Podívat se jak se vyvinuly některé služby. Vidět je tak jak by je viděl někdo, kdo je nikdy nepoužil a…
