Přeskočit na obsah

Úvod / Případy z praxe

Občasné zpomalení o 3 sekundy bez viníka mezi pluginy

Příznaky

Z mezipaměti se stránky načítaly asi za 0,15 s. Bez ní (košík, pokladna, přihlášení, první návštěva po vyčištění cache) to kolísalo mezi 0,8 a 4 s. Pocitově „web je občas líný“.

Prostředí

WordPress s WooCommerce, page builderem a kolem 40 aktivními pluginy, sdílený hosting s LiteSpeedem a jeho cache.

Diagnostika

  1. Opakované měření. Několik stránek jsme mimo cache načítali každých 75 s po dobu několika minut. Zpomalení nebylo vázané na úvodní stránku: stejně často se týkalo i obyčejné textové stránky. Asi polovina požadavků v sérii měla +3 s. Rovné 3 s navíc vypadaly jako timeout vnějšího volání (licenční server, API, fonty).
  2. Dočasný diagnostický mu-plugin (se souhlasem, bez osobních údajů). Logoval čas do hlavních fází požadavku (muplugins_loaded, plugins_loaded, init, wp_loaded, template_redirect, shutdown) a každé vnější HTTP volání přes filtry pre_http_request a http_api_debug.
  3. Výsledek byl překvapivý: pomalé požadavky (asi 3,3 s, zhruba jeden z patnácti) neměly žádné vnější HTTP volání. Zpomalené byly všechny fáze rovnoměrně, nejvíc start do plugins_loaded (1,3 s místo 0,12 s). Žádný plugin tedy nevyčníval.
  4. Mu-plugin i jeho log jsme hned po měření smazali a ověřili, že adresa vrací 404.
Pomalý požadavek je pomalejší ve všech fázích Zhruba každý patnáctý požadavek trval přes 3 sekundy. Rozpad na fáze ukázal, že se zpomalily všechny fáze rovnoměrně a nebylo žádné vnější volání. To ukazuje na studený start PHP, ne na plugin. Doba odpovědi mimo cache 3,3 s běžně 0,8–1 s Kde se čas ztrácí (fáze WordPressu) rychlý pomalý Všechny fáze delší stejným dílem, bez vnějších volání → studený start PHP.
Zhruba každý patnáctý požadavek trval přes 3 sekundy. Rozpad na fáze ukázal, že se zpomalily všechny fáze rovnoměrně a nebylo žádné vnější volání. To ukazuje na studený start PHP, ne na plugin.

Příčina

Rovnoměrné zpomalení celého požadavku bez vnějších volání odpovídá studenému PHP procesu na sdíleném hostingu. Požadavek dostane nový proces s prázdnou opcache, který musí znovu načíst a zkompilovat kód všech pluginů. Plugin ani web za to nemůže.

Co hrozí, když se to neřeší

Pomalé jsou právě stránky, na kterých se vydělává: košík, pokladna a účet zákazníka. Každá sekunda čekání navíc zvyšuje počet opuštěných košíků a Google pomalou odpověď serveru započítává do hodnocení rychlosti. Hledání viníka mezi pluginy navíc stojí čas i peníze za zbytečné zásahy.

Oprava

Na straně webu není co opravit. Doporučili jsme:

  • zeptat se podpory hostingu na počet PHP procesů, jak dlouho žijí a jakou velikost má opcache,
  • dlouhodobě snížit počet aktivních pluginů, aby studený start trval kratší dobu.

Návštěvníků, kterým se stránky načítají z cache, se to netýká.

Ověření

Hlavní zjištění bylo vyloučení: žádné vnější volání a žádný jednotlivý plugin. Tím jsme si ušetřili hodiny vypínání pluginů naslepo.

Prevence a ponaučení

Než začnete hledat viníka mezi pluginy, změřte, které fáze požadavku se zpomalují. Když se zpomalí všechny stejně, problém je pod WordPressem (PHP, disk, hosting), ne v něm.

Související služby: Havárie a chyby Zrychlení webu

Máte podobné příznaky?

Napište mi adresu webu a jaké má příznaky. Diagnostika je zdarma a nezávazná. Ozvu se obvykle do jednoho pracovního dne.

Popsat příznaky

nebo rovnou e-mailem na [email protected]