Jak dlouhé PHP procesy způsobily výpadek e-shopu
E-shopu nejdřív přestal fungovat košík, pak celý web. Vypadalo to jako klasický nápor návštěvnosti od reklamních kampaní, jenže skutečná příčina byla jinde – ve způsobu, jakým web zpracovává URL s marketingovými parametry.
Zveřejněno: 24. 3. 2026
Výchozí situace
Nejdřív přestal fungovat košík, následně celý e-shop. Server byl restartován, po chvíli web naběhl, ale znovu spadl. Cílem bylo web zprovoznit, najít skutečnou příčinu a navrhnout další opatření, pokud budou potřeba.
Klient provozuje e-shop na WordPressu (WooCommerce) s pravidelnými marketingovými kampaněmi, které přivádí návštěvnost přes reklamní odkazy s trackovacími parametry.
Cíle a výzvy
Obnovit funkčnost e-shopu – košík i celý web
Najít skutečnou příčinu opakovaného výpadku
Ověřit, jestli šlo o nápor návštěvnosti, nebo o něco jiného
Navrhnout opatření proti opakování problému
Výsledky
92%
Pokles zátěže CPU po zásahu
3
Úpravy nastavení serveru a cache
1
Zásah k trvalému vyřešení
Co jsme zjistili
Podpora hostingu našla dlouho běžící požadavky na hlavní vstupní skript webu. Šlo o požadavky obsahující marketingové parametry (např. utm_source, gclid, fbclid a podobné) – některé běžely přibližně 1400 až 1600 sekund. Server vykazoval problematický stav a vytížení CPU až 100 %.
Podle podpory dlouho běžící PHP procesy spotřebovávaly serverové prostředky, a URL s query parametry navíc mohou obcházet cache, takže je web musí zpracovat přes PHP a databázi místo rychlejší cachované odpovědi. Samotné kampaně s trackovacími parametry přitom neměly být důvodem, proč by tak výkonný server spadl – problém byl spíš v tom, že některé procesy běžely extrémně dlouho. V logu chyb se objevila i upozornění vázaná na plugin Toret Zásilkovna a na jeden další, klientský plugin, ale nepotvrdilo se, že by šlo o jednoznačnou příčinu výpadku.
Jak jsme postupovali
Nejdřív jsme ve spolupráci s podporou hostingu restartovali server a služby a ověřili, že fungují stránky i přidání do košíku. Konzultovali jsme dlouhé požadavky s marketingovými parametry a upravili nastavení cache tak, aby dokázala cachovat i požadavky s query parametry – klienta jsme upozornili, že je po této změně potřeba sledovat případný dopad na kampaně a remarketing.
Zkontrolovali jsme nastavení serveru, logy a naplánované úlohy, snížili jsme paměťový limit a maximální dobu zpracování požadavku na rozumnější hodnoty a upravili limity databázového připojení. Zapnuli jsme podrobnější logování pro další sledování a přidali pravidlo proti neověřeným botům.
- Restart serveru a služeb ve spolupráci s podporou hostingu
- Ověření, že po restartu fungují stránky i přidání do košíku
- Konzultace ohledně dlouhých požadavků s marketingovými parametry
- Nastavení cache tak, aby cachovala i požadavky s query parametry
- Upozornění na nutnost sledovat dopad této změny na kampaně a remarketing
- Kontrola nastavení serveru, logů a naplánovaných úloh
- Snížení paměťového limitu a maximální doby zpracování požadavku
- Úprava limitů databázového připojení
- Zapnutí podrobnějšího logování pro další sledování
- Přidání pravidla proti neověřeným botům
Sledovali jsme vytížení CPU postupně po každé úpravě, abychom viděli, která změna má skutečný dopad.
Výsledek zásahu
Web po zásahu fungoval – košík i běžné stránky byly znovu funkční. Server se podle monitoringu přestal tolik zatěžovat. Stejný konkrétní problém (dlouho běžící procesy u URL s marketingovými parametry) se od zásahu znovu neobjevil, i když web měl později ještě jiná zpomalení s jinou, nesouvisející příčinou. Náš interní tiket nedokládá jednoznačné odstranění konkrétní chyby v pluginu, šabloně, databázi nebo externím API – šlo především o omezení dopadu přes nastavení serveru a cache.
Praktické detaily
Běžné reklamní parametry v URL nejsou samy o sobě problém. V tomto případě ale mohly obcházet cache, takže je web musel zpracovat přes PHP a databázi – a pokud takový proces běží extrémně dlouho, dokáže zatížit server podobně jako reálný nápor návštěvnosti.
Klíčové bylo porovnat několik věcí najednou:
- Skutečnou návštěvnost webu v době výpadku
- Dobu běhu jednotlivých PHP procesů
- Nastavení cache u URL s query parametry
- Vytížení CPU podle monitoringu serveru
Poučení a nová zjištění
U e-shopu je potřeba sledovat nejen návštěvnost, ale i to, jak web zpracovává URL s parametry. Dlouho běžící PHP proces u zdánlivě neškodného reklamního odkazu dokáže zatížit server stejně jako reálný nápor návštěvnosti.
Než se výpadek vyhodnotí jako „nápor návštěvnosti“, vyplatí se ověřit, jestli nejde o technický problém ve zpracování konkrétního typu požadavků.
Nová zjištění, která z případu vyplynula pro podobné situace:
- URL s marketingovými parametry mohou obcházet cache a nutit web zpracovávat každý požadavek zvlášť.
- Dlouho běžící PHP proces dokáže zatížit server stejně jako reálný nárůst návštěvnosti.
- Změna nastavení cache kvůli výkonu může ovlivnit měření kampaní – je potřeba to sledovat.
- Chyby zachycené v logu nemusí být hlavní příčinou výpadku – je třeba je ověřit zvlášť, ne automaticky spojovat.
Připravil tým WP-admin.cz
Vyřešíme váš problém s WordPressem
Zaujal vás náš článek? Pomozte někomu a podělte se:
Nepřehlédněte naše další případovky
Nejste si jistí, kde začít? Pojďme se spojit!
Projdeme s vámi aktuální stav vašeho webu a navrhneme další postup.
Domluvit nezávaznou konzultaciNezávazná 20 min. technická konzultace
