Neu Massive 504 Timeouts bei Bot-Crawl (JTL-Hosting) – PHP-Worker-Pool als Flaschenhals?

[WITTKO]

Hallo zusammen,

ich wende mich an die Community (und hoffentlich an das JTL- Hosting-Team), da unser Shop aktuell massive Stabilitätsprobleme hat.

Das Szenario:

• Hosting: JTL-Hosting, langjähriger Bestandskunde (über 10 Jahre).
• Shop: JTL-Shop 5.6 mit ca. 10K Artikeln und vielen technischen Merkmalen/Filtern.
• Status: Redis ist aktiv und konfiguriert.

Das Problem: Sobald Googlebot oder Bingbot mit normaler Frequenz (Sekunden-Takt) anfangen zu crawlen, läuft der Shop sofort in den 70007: The timeout specified has expired Fehler (504 Gateway Timeout). Der Shop ist dann weder für Kunden noch für uns im Admin erreichbar.

Bisherige Analyse: Die Logs zeigen, dass die Anfragen sauber am nginx ankommen, aber der Apache/PHP-Stack dahinter nicht antwortet. Da Redis aktiv ist und die DB entlastet, liegt der Verdacht nahe, dass der PHP-FPM Pool (pm.max_children) viel zu klein dimensioniert ist.

Aktuell können wir den Shop nur online halten, indem wir die Suchmaschinen-Bots per .htaccess (403) komplett aussperren. Das ist für einen E-Commerce-Betrieb natürlich ein untragbarer Zustand (SEO-Suizid).

Meine Fragen:

1. Gibt es beim Standard-Hosting Möglichkeiten, die PHP-Worker-Anzahl (Slots) kurzfristig zu erhöhen?
2. Warum greift das Rate-Limiting auf nginx-Ebene im JTL-Cloud-Hosting nicht, um solche Burst-Anfragen von Crawlern abzufangen, bevor sie die PHP-Worker belegen?
3. Hat jemand ähnliche Erfahrungen mit "Alt-Verträgen" nach dem Umzug auf die offensichtlich neue Infrastruktur gemacht?

Ich habe bereits ein Ticket (202602073600051) offen, aber die Zeit drängt, da wir aktuell ohne Crawling operieren müssen.

Über technisches Feedback oder eine Reaktion seitens JTL wäre ich sehr dankbar.

 

[WITTKO]

Ergänzung: Hier sieht man extrem gut, wie der Bingbot (52.167.144.192) versucht, endlose Filter-Kombinationen (?suchausdruck=...&fq0=attr_str_widerstandswert...) abzugreifen. Obwohl wir mit 403 antworten, reicht die schiere Menge dieser komplexen URL-Anfragen aus, um die Instanz lahmzulegen. Das zeigt, dass das JTL- Hosting hier ein massives Problem mit der Vorfilterung solcher Bot-Bursts hat.

 

[css-umsetzung]

Bisherige Analyse: Die Logs zeigen, dass die Anfragen sauber am nginx ankommen, aber der Apache/PHP-Stack dahinter nicht antwortet. Da Redis aktiv ist und die DB entlastet, liegt der Verdacht nahe, dass der PHP-FPM Pool (pm.max_children) viel zu klein dimensioniert ist.

In der Regel ist es die Datenbank, die den Serverload dann hochschraubt.
Ich habe bereits vielen Kunden geholfen, die Probleme mit Bots haben.

Unter anderem kannst du über robots.txt auch die Crawler Geschwindigkeit herabsetzen, das nutzt dir aber nur bei den regulären Bots etwas.

lies dir das hier mal durch
https://forum.jtl-software.de/threads/crawlerproblem.243288/

https://forum.jtl-software.de/threads/robots-txt-wie-richtig-einstellen.238824/