Neu JTL Shop 5 ... REDIS Cache läuft stündlich voll

[Rektor]

Wir hatten einen Shop auf REDIS umgestellt mit genug RAM, läuft jetzt 1A.

Im ersten und weiteren Posts hast du behauptet, das alles auf REDIS läuft. Jetzt auf einmal habt Ihr einen Shop auf REDIS umgestellt.

Weißt du überhaupt, worüber du redest?

Der Umzug auf einen neuen Server, wie css-umsetzung bereits beschrieben hat, ist ein "Kinderspiel". Alle Daten, auch E-Mails und Tools werden komplett auf dem neuen Server abgebildet. Ganz so viel Ahnung von einem Server und dem Umzug auf einen anderen Server hast du sicherlich nicht...

 

[wawi-dl]

@Rektor
wir fahren aktuell Tests, auf anraten von JTL (siehe Post) haben wir auf sqlite3 umgestellt, was aber den Speicher gesprengt hat und Amok gelaufen ist, Webspace voll und Server tot.
Unser Hoster hat uns angeraten das schnellstens wieder abzuschalten, haben daher wieder REDIS aktiviert.

Aktuell testen wir Performance 32GB zu 16GB, mit 32GB läuft es super, aber die Kosten wären auch doppelt so groß. Kommende Woche testen wir 16GB und schauen mal wie es wird.

Sobald wir hier fertig sind, können wir auch Anweisungen von CSS-Umsetzung mal anschauen.

 

[Rektor]

Sobald wir hier fertig sind, können wir auch Anweisungen von CSS-Umsetzung mal anschauen.

Wäre es nicht besser, CSS-Umsetzung gleich mit der Aufgabe zu betrauen, zumal der Dienstleister bestimmt mehr Erfahrung von Hostern und deren Abläufe hat, als Ihr jemals haben werdet. Durch Betreuung verschiedener Kunden und dementsprechend der Hoster, kennt CSS-Umsetzung bestimmt die Vor- und Nachteile der einzelnen Hoster bzw. deren stärken und Schwachstellen.
CSS-Umsetzung stellt ausserdem keine Anweisungen, sondern Empfehlungen bereit, das alles kostenlos...

 

[wawi-dl]

Unser Hoster hat paar Dinge angepasst, die 3 Shops liefen mit 32GB jetzt stabil und nichts ging in die Knie.

Wir wollen nicht an der Grenze rumschruppen, daher Test mit aktueller Last/Anforderung.

Wir reduzieren jetzt auf 16GB und schauen was passiert.

Anschließend schauen wir, wie wir Bots wie BingBot sperren können, der funkt offenbar auch rein.

Da viele Tools über MySQL DB auf dem Server laufen, muss dieser Stabil bleiben, da sonst die Tools streiken.
Daher ist auch ein Umzug nicht ohne weiteres möglich, der Rattenschwanz ist groß, auch für unsere Kunden.

 

[wawi-dl]

 

[hula1499]

Schaut doch gut aus, bei 32 GB.

Mit einem downgrade auf 16 GB wirst wieder wieder an der Überlastung kratzen. Die Aufstellung braucht schon 32 GB um auch noch etwas selbst atmen zu können.

 

[css-umsetzung]

Anschließend schauen wir, wie wir Bots wie BingBot sperren können, der funkt offenbar auch rein.

Das hätte das erste sein müssen was du tun solltest, da der rasante Anstieg des Cache einfach nicht normal ist.

 

[wawi-dl]

Das hätte das erste sein müssen was du tun solltest, da der rasante Anstieg des Cache einfach nicht normal ist.

Danke, könntest du uns helfen, wie man diesen "bingbot" aussperrt?

 

[css-umsetzung]

Wie man die Bots aussperrt hatte ich hier in diesem Beitrag schon geschrieben, das kannst du alles ganz einfach selbst machen, dann ist das kostenlos.
https://forum.jtl-software.de/threa...ft-stuendlich-voll.210099/page-2#post-1122889

Und wie man Bing in seine Schranken weist hatte ich auch in diesem Beitrag geschrieben, bzw. den Link zu @MHillmann seinem Post verlinkt.
https://forum.jtl-software.de/threa...n-fehler-abgelehnt.209842/page-2#post-1122908

Wenn du das nicht selbst machen möchtest, ja klar dann kann ich das machen aber es sind ja wirklich nur zwei Dateien in denen du etwas ändern musst.

 

[wawi-dl]

Danke, haben wir nun mal aktiviert und beobachten.

In einem Shop hatten wir 50.000 BingBot, die großen sind "spider" und "robots", die aber sicherlich iO und erforderlich sind.

 

[css-umsetzung]

Die in meiner Sperre enthaltenen sind nicht wichtig.

 

[tresor-online]

Ich grätsch hier auch noch mal rein...

Wenn euer Redis aussteigt weil der cache voll ist, also deswegen einen 500er produziert, dann solltet Ihr diese Einstellung prüfen lassen.
https://redis.io/docs/reference/eviction/

Bei uns ist Redis auch wieder ein Thema, nachdem es da die Woche wieder zu Problemen gekommen ist.
Unser Host hat jetzt 20GB für Redis freigegeben, die aber schon dauerhaft belegt sind.
Key Eviction war bis gestern nichts eingestellt, wurde jetzt auf XXX gesetzt.
Zitat Hoster:

ich habe nun "maxmemory-policy volatile-lfu" gesetzt, da JTL offenbar Keys mit und ohne Ablaufzeit ablegt. Ich denke jene ohne Ablaufzeit sollte nicht einfach gelöscht werden.

Ist das okay so, oder was wäre denn die ideale Einstellung für Key Eviction?

In der config.ini haben wir das Code-Schnipsel am Ende schon in allen 3 Shops drinnen.
Habe gestern noch die robots.txt angepasst.

Mir fällt es nur so schwer zu glauben, dass es "normal" ist, dass mit unseren 3 Pipifatz Shops der Redis Cache so voll wird.

Hoster empfiehlt mehr RAM, aber das scheint mir eher Symptom Bekämpfung, mal abgesehen von den nicht unerheblichen Mehrkosten im Monat

 

[css-umsetzung]

Ich bin eher für volatile-ttl und ich finde es übertrieben da 20G für bereitzustellen, klar das sich das System alles nimmt was es bekommen kann.

 

[tresor-online]

Danke für den Tipp, habs mal an den Host weitergeben und dann schauen wir mal, wie es läuft.

 

[mh1]

Weil es dafür kein Plugin gibt,

Ich verwende das hier in der config.jtl- shop.ini.php am Ende der Datei

if(!empty($_SERVER['HTTP_USER_AGENT']) && preg_match("/Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot|Bytespider/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

Unabhängig von dem REDIS Thema nur eine Anmerkung zu den Sperren.
Ich würde solche Filter immer so früh wie möglich ausführen. Also noch bevor sich PHP damit rumschlagen muss, oder im Idealfall noch bevor der Traffic zum Webserver geleitet wird.
Natürlich kann man wenn man z.b. ein normales Webhosting hat nicht in die Firewall/Netzwerkfilter eingreifen oder vor den Webserver einen Proxy installieren oder so... Aber manch einer hat ja vollen Zugriff auf seine Server

 

[tresor-online]

Unabhängig von dem REDIS Thema nur eine Anmerkung zu den Sperren.
Ich würde solche Filter immer so früh wie möglich ausführen. Also noch bevor sich PHP damit rumschlagen muss, oder im Idealfall noch bevor der Traffic zum Webserver geleitet wird.
Natürlich kann man wenn man z.b. ein normales Webhosting hat nicht in die Firewall/Netzwerkfilter eingreifen oder vor den Webserver einen Proxy installieren oder so... Aber manch einer hat ja vollen Zugriff auf seine Server

guter Hinweis, ich werde das mal mit meinem Hoster klären, ob das geht.

 

[css-umsetzung]

Ich würde solche Filter immer so früh wie möglich ausführen. Also noch bevor sich PHP damit rumschlagen muss, oder im Idealfall noch bevor der Traffic zum Webserver geleitet wird.

Ja, im Grunde hast du recht aber das kann man echt vernachlässigen, ich habe ja von mehreren Kunden die dedicated Server in der Verwaltung und sehe ja ob sich das bei der Last bemerkbar macht und muss sagen das dies der einfachste Weg ist, auch um das mal schnell zu erweitern und wenn ich sehe, das der Serverload, "damals als es das andere Bot Problem gab" dann von ü50 auf 1.xx runtergeht bei einer 8 Core Maschine, dann ist der php Prozess nicht wirklich relevant.

Hinzu kommt das es momentan eher Probleme gibt weil die Merkmale das System crashen, weil MySQL bei einer 8 Core Maschine dann mit 8 Requests alle 8 Cores zu 100% auslastet und sich dann nichts mehr bewegt.
MySQL was in diesem Fall das Hauptproblem ist, wird nun ja nicht gestartet, also hilft diese einfache Lösung da auch wieder.

Und der php Prozess oder das Kind eines Prozesses läuft ja im Grunde nicht mal 100ms um sich darum zu kümmern.

 

[css-umsetzung]

guter Hinweis, ich werde das mal mit meinem Hoster klären, ob das geht.

Der Hoster wird dir was Husten wenn du dem sagst meine Software ist schlecht programmiert, bitte passe mal deinen Server an und sperre alle Bots die ich nicht mag

 

[mh1]

Ja, im Grunde hast du recht aber das kann man echt vernachlässigen, ich habe ja von mehreren Kunden die dedicated Server in der Verwaltung und sehe ja ob sich das bei der Last bemerkbar macht
....
Und der php Prozess oder das Kind eines Prozesses läuft ja im Grunde nicht mal 100ms um sich darum zu kümmern.

Ah ja, das ist natürlich auch ein gutes Argument... an die Betrachtung der Serverlast hab ich jetzt gar nicht gedacht. Aber du hast recht: Wenn man nur die Serverlast betreachtet, dann spielt es wohl keine Rolle, ob man ungewünschten Traffic erst von der PHP-App oder schon im Vorfeld ausfiltern lässt.

Ich bin da halt zu sehr old-school und Pakete an meinen Webserver weiterzuleiten, nur um sie dort von einem userspace filter wieder zu blocken, fühlte sich "irgendwie falsch" an 😌
Aber stimmt, in Zeiten von Gigabit Netzen und sich langweilenden Xeons mit x GB RAM ist das eigentlich wurscht

 

[tresor-online]

Der Hoster wird dir was Husten wenn du dem sagst meine Software ist schlecht programmiert, bitte passe mal deinen Server an und sperre alle Bots die ich nicht mag

Haha, okay. Gut, dann erspar ich mir und meinem Hoster diese Nachricht und bleib bei der Implementierung in der config.ini! 😅
Wir haben jetzt auch mal auf volatile-ttl umgestellt und werden das jetzt beobachten.