Pomalý web nebo chyby 5xx: diagnostika na sdíleném hostingu

Když je web na sdíleném hostingu pomalý nebo vrací chyby 5xx, nejdřív měřte a potom čtěte logy: TTFB přes curl pro stránku a pro statický soubor, přesný chybový kód, chybový log, limity prostředků a nakonec databázi, externí služby a přístupový log. Toto pořadí vede od nejlevnějších kontrol k nejnáročnějším. I když příčinu sami nenajdete, budete mít přesně ta data, která potřebuje podpora.

Přehled: příznak, kontrola, řešení

Krok 1: změřte TTFB přes curl, ne podle pocitu

Podle příručky Googlu na web.dev zahrnuje TTFB (Time to First Byte) přesměrování, DNS dotaz, navázání spojení, vyjednání TLS a čekání na první bajt odpovědi. Příručka považuje 0,8 sekundy a méně za dobrou hodnotu a více než 1,8 sekundy za špatnou. Měřte několikrát po sobě:

for i in 1 2 3 4 5; do
  curl -s -o /dev/null -w 'dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}  code %{http_code}\n' https://example.com/
done

Pole jsou proměnné write-out nástroje curl: time_namelookup (DNS), time_connect (TCP spojení), time_appconnect (TLS handshake), time_starttransfer (první bajt včetně času, který server potřebuje na vytvoření odpovědi) a time_total. Potom změřte statický soubor, který PHP nezpracovává:

curl -s -o /dev/null -w 'ttfb %{time_starttransfer}  code %{http_code}\n' https://example.com/robots.txt

• Už dns nebo connect jsou vysoké: problém je v DNS nebo v síti, ne v PHP. Měření zopakujte z jiné sítě.
• Statický soubor rychlý, stránka pomalá: webový server odpovídá rychle a čas se ztrácí v PHP a databázi. Pokračujte kroky 3 až 5.
• Obojí pomalé: server nebo jeho síť jsou přetížené, případně váš účet naráží na limity. Pokračujte krokem 4 a podporou.
• TTFB dobré, stránka přesto pomalá: čas spotřebuje frontend. Cache, kompresi a nastavení PHP popisuje náš článek o konfiguraci serveru pro rychlost webu.

Pokud je TTFB v pořádku a pomalu se stahují hlavně velké soubory, příčinou může být omezení rychlosti přenosu ze strany hostingu, které ověříte měřením rychlosti stahování v curl v různých denních dobách.

Měřte z regionu, kde jsou vaši návštěvníci, a bez přihlášení: mnoho CMS přihlášeným uživatelům neposílá stránky z cache.

Krok 2: co prozradí chybový kód

Zapište si přesný kód a čas. Definice vycházejí z RFC 9110 a MDN, typické příčiny se týkají sdíleného hostingu.

Krok 3: přečtěte chybový log a chyby PHP

V ovládacím panelu otevřete logy domény a přepněte na chybové logy; panely tuto sekci nazývají například “Error Logs” nebo “Logs”. S přístupem přes SSH stačí dva příkazy (cestu uvidíte v panelu nebo vám ji sdělí podpora):

tail -n 100 /path/to/error.log
grep -i -E "fatal|memory|timed out|max_children" /path/to/error.log | tail -n 20

Časté záznamy a jejich význam:

• Allowed memory size of ... bytes exhausted: skript překročil memory_limit. Obvykle jde o plugin nebo velký import.
• Maximum execution time of 30 seconds exceeded: skript běží déle, než dovoluje max_execution_time.
• upstream timed out (Nginx): webový server čekal na PHP příliš dlouho, typický zdroj chyby 504.
• server reached pm.max_children (PHP-FPM, pokud hostitel tento log zpřístupňuje): všechny procesy PHP jsou obsazené, požadavky čekají nebo končí chybou 502 či 503.

Ve WordPressu zapněte zápis chyb v souboru wp-config.php, aniž byste je ukazovali návštěvníkům:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Podle dokumentace WordPressu se záznam pak ukládá do wp-content/debug.log. Po diagnostice konstanty vypněte a soubor smažte: leží ve veřejné složce. Pro samotné PHP doporučuje manuál PHP na produkčních serverech display_errors = Off a log_errors = On.

Pokud se chyby objevily hned po aktualizaci, zkontrolujte v panelu, jaká verze PHP je pro doménu zvolená a zda jsou zapnutá rozšíření, která web potřebuje. Chyby paměti a času běhu závisí na platných limitech PHP: dočasný soubor s phpinfo() ukáže hodnoty, se kterými pracuje webový server (hned ho smažte), kdežto php -i přes SSH ukáže nastavení příkazové řádky, které se může lišit:

php -i | grep -E "memory_limit|max_execution_time|upload_max_filesize|post_max_size"

Podle manuálu PHP jsou výchozí hodnoty memory_limit 128M, max_execution_time 30 sekund (v příkazové řádce 0), upload_max_filesize 2M a post_max_size 8M; php.ini vašeho hostitele může nastavit jiné. Pro nahrávání velkých souborů musí být post_max_size větší než upload_max_filesize.

Krok 4: zkontrolujte limity prostředků

Na sdíleném hostingu sdílí jeden server mnoho účtů, proto má každý účet limity. Na serverech s CloudLinuxem jsou to podle dokumentace SPEED (CPU), PMEM (fyzická paměť), IO, IOPS, EP (souběžné Entry Processes) a NPROC (procesy). Při překročení EP uvidí návštěvník chybu 508; při vyčerpání paměti nebo počtu procesů chybu 500 nebo 503. Jiné platformy omezují prostředky jinak: zeptejte se poskytovatele, jaké limity platí a kde uvidíte jejich historii.

Rozhodující je časové srovnání: kryjí se zpomalení se špičkami v grafu prostředků? Běží v tu dobu úlohy cronu, zálohy, importy nebo newslettery? Jak tyto hodnoty sledovat trvale a nastavit upozornění, popisuje náš návod k monitoringu serveru.

Krok 5: pomalé dotazy a externí služby

Slow query log v MySQL je ve výchozím stavu vypnutý, práh long_query_time je podle manuálu MySQL 8.4 10 sekund a na sdíleném hostingu obvykle chybí oprávnění zapnout ho globálně. Místo toho:

• SHOW PROCESSLIST v phpMyAdminu nebo v klientovi MySQL: bez oprávnění PROCESS vidíte jen svá vlastní spojení, což pro váš web stačí. Podezřelé jsou dotazy, které několik sekund visí ve stavu “Sending data” nebo “Locked”.
• Plugin Query Monitor ukazuje ve WordPressu pomalé, duplicitní a chybné dotazy, chyby PHP a volání HTTP API s jejich délkou.
• Konstanta SAVEQUERIES ukládá všechny dotazy do $wpdb->queries. Zpomaluje web, proto ji zapínejte jen krátce.

Indexy, čištění tabulek a cache dotazů rozebírá náš článek o optimalizaci databáze na hostingu.

Externí služby často brzdí nenápadně: platební brány, kurzy měn, ověřování licencí, sociální feedy. Když PHP čeká na cizí API, TTFB roste, i když váš server nic nedělá. HTTP API WordPressu čeká ve výchozím stavu až 5 sekund na každý požadavek, takže několik pomalých volání se sčítá. Řešení: cachovat odpovědi, přesunout volání do cronu, odstranit pluginy se zbytečnými vzdálenými požadavky.

Krok 6: špičky provozu a boti v přístupovém logu

Přístupový log ukazuje, kdo zátěž vytváří. Pro obvyklý formát combined:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print substr($4,2,17)}' access.log | sort | uniq -c | sort -rn | head
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head
awk '$9 ~ /^5/ {print $9}' access.log | sort | uniq -c

• Řádky 1 a 2: nejaktivnější IP adresy a nejčastěji požadované URL.
• Řádek 3: požadavky za minutu, tedy špičky.
• Řádek 4: user agenty, tedy jací boti přicházejí.
• Řádek 5: odpovědi 5xx podle kódu.

Varovné signály: několik IP adres nebo jediný user agent tvoří většinu požadavků; mnoho přístupů na wp-login.php, xmlrpc.php, vyhledávání nebo URL filtrů s parametry, které obcházejí cache. Zda je bot opravdu Googlebot, ověříte podle návodu Googlu dvojím DNS dotazem: název musí končit na googlebot.com, google.com nebo googleusercontent.com a ukazovat zpět na stejnou IP adresu.

host 66.249.66.1
host crawl-66-249-66-1.googlebot.com

Agresivní boty zablokujte v panelu nebo v souboru .htaccess. Omezování požadavků bez falešných poplachů popisuje článek o chybě 503. Pokud je nápor skutečný, třeba po kampani, pomůže cache stránek, a když se limity i tak trvale dosahují, vyšší tarif.

Optimalizovat, nebo změnit tarif?

Nejdřív optimalizujte, pokud jsou prostředky volné a web je přesto pomalý, pokud logy ukazují chyby pluginů nebo dotazů, nebo pokud je TTFB dobré a brzdí jen frontend. Vyšší tarif má smysl, když se limity i po optimalizaci pravidelně dosahují. U RichHost začínají tarify sdíleného hostingu na A3 za 8 USD a končí na A50 za 65 USD měsíčně, všechny s NVMe disky a vlastním ovládacím panelem s asistentem AI; podrobnosti najdete na stránce tarify hostingu. Před každou změnou a po ní porovnejte stejná měření curl.

Co poslat podpoře

• Dotčenou URL a přesný čas včetně časového pásma.
• Chybový kód a text chybové stránky.
• Výstup curl z pěti měření pro stránku a statický soubor a svou veřejnou IP adresu.
• Příslušné řádky z chybového logu nebo debug.log.
• Co se v poslední době změnilo: aktualizace, nové pluginy, DNS, kampaně.
• Co jste už zkusili, a konkrétní otázku: jaký limit byl dosažen, kdy a kterým procesem?

Časté otázky

Jaké TTFB je normální?

Podle web.dev je 0,8 sekundy a méně dobré, víc než 1,8 sekundy špatné. Měřte několikrát, bez přihlášení a z regionu vašich návštěvníků.

Proč je web u mě rychlý a u zákazníků pomalý?

Možné důvody: dostáváte verzi z cache, zákazníci jsou dál od serveru nebo mají pomalý DNS resolver. Spusťte příkaz curl z jiné sítě a porovnejte dns, connect a ttfb.

Je chyba 508 totéž co 503?

Obě ukazují na přetížení. Chybu 508 “Resource Limit Is Reached” zobrazují servery s CloudLinuxem, když je dosažen limit souběžných Entry Processes. Chyba 503 je širší: přetížení, plný pool procesů nebo údržba.

Můžu na sdíleném hostingu zapnout slow query log?

Obvykle ne, potřebujete globální oprávnění na serveru. Použijte Query Monitor nebo SHOW PROCESSLIST, případně požádejte podporu o výpisy pro svou databázi.