Neu Shop manchmal extrem langsam - php-fpm

[tresor-online]

Hallo zusammen!
Wir haben gerade unseren ersten Shop endlich von JTL Shop 3 auf JTL Sho 5 aktualisiert.
Soweit läuft auch alles ganz gut.
Nur ein großes Problem haben wir:
Der Shop ist immer wieder mal extrem langsam.
Unser Host All-Inkl sagt dazu folgendes:

Wir können feststellen, dass der Account, in dem die Domain liegt, hier öfters ins PHP-FPM-Limit läuft. Dieses Limit ist für jeden Server gleich und schützen diesen vor Überlastung durch einen einzelnen Kundenaccount.
Grundsätzlich bedeutet dies, dass sich PHP-Prozesse im Account aufstauen. Dadurch können keine neuen Prozesse mehr angestoßen werden. Dies resultiert in längeren Ladezeiten der Seite bis hin zum Abbruch des Aufrufs und somit zu zeitweise nichterreichbarkeiten.
Sie müssten hier Ihre Seite prüfen, um die eventuell langlaufenden PHP-Prozesse zu identifizieren und dann dementsprechend zu optimieren.

Es wurde auch eine Log-Datei erstellt, die Einträge erstellt, wenn das passiert.
Diese sehen dann so aus:

[20-Apr-2023 15:00:06]  [pool XXXXXXXX] pid 19308
script_filename = /www/htdocs/XXXXXXXX/tresor_online_at/io.php
[0x00007fcd1d2144f0] session_start() /www/htdocs/XXXXXXXX/tresor_online_at/includes/src/Session/AbstractSession.php:116
[0x00007fcd1d214480] start() /www/htdocs/XXXXXXXX/tresor_online_at/includes/src/Session/AbstractSession.php:82
[0x00007fcd1d2143f0] initCookie() /www/htdocs/XXXXXXXX/tresor_online_at/includes/src/Session/AbstractSession.php:36
[0x00007fcd1d214360] __construct() /www/htdocs/XXXXXXXX/tresor_online_at/includes/src/Session/Frontend.php:63
[0x00007fcd1d2142d0] __construct() /www/htdocs/XXXXXXXX/tresor_online_at/includes/src/Session/Frontend.php:51
[0x00007fcd1d214230] getInstance() /www/htdocs/XXXXXXXX/tresor_online_at/includes/globalinclude.php:120

Wir hatten so was ähnliches schon einmal im alten Shop, damals lag es an einem Plugin, ich habe dieses dann deaktiviert. Das Problem blieb aber bestehen.

Bin für jede Hilfestellung dankbar.

 

[css-umsetzung]

Ich würde über die config datei zuerst die Bad bots aussperren.
Dann würde ich schauen ob es nicht mehr Sinn macht auf einen eigenen Server zu gehen, ab einer bestimmten Menge an Usern macht ein normales Hosting keinen Sinn mehr.

 

[tresor-online]

Ich würde über die config datei zuerst die Bad bots aussperren.

Hier würde ich gerne mehr Information dazu bekommen, was wie wo da zu tun ist

@eigener Server: ja, das ist immer wieder mal im Gespräch, aber eigentlich haben wir nicht so viele User.
Außerdem tritt das Problem ja jetzt erst auf seit wir von JTL Shop 3.20 (spät aber doch) auf JTL Shop 5.1.5 umgestellt haben.

 

[css-umsetzung]

Wenn dein Hoster sagt das zu viele Prozesse gestartet dann gibt es ja eben verschiedene Möglichkeiten, vier davon sind eben

1. Schlechte Shop Konfiguration
2. Zu klein dimensioniertes Hosting
3. Extrem viele Zugriffe über Bad Bots
4. Extrem viele Besucher

Bei dir, wenn ich mir die eine Seite anschaue würde ich eventuell auf eine schlechte Konfiguration tippen, beim Aufruf der Seite (hab nur grob geschaut ohne das richtig zu analysieren muss jemand genauer anschauen) werden 68 JavaScripts geladen, dass ist schon ein wenig viel.

Das der Shop selbst das Problem ist glaube ich nicht, dann hätten wir wir hier einen Ansturm von Meldungen das Hoster ausflippen, daher wird es mindestens einer dieser Punkte sein.


Das hier unten am Ende der config Datei einfügen dann hast du das grobe schon mal ausgesperrt so das die keine unnötigen Ressourcen fressen.

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

 

[tresor-online]

Wenn dein Hoster sagt das zu viele Prozesse gestartet dann gibt es ja eben verschiedene Möglichkeiten, vier davon sind eben

1. Schlechte Shop Konfiguration
2. Zu klein dimensioniertes Hosting
3. Extrem viele Zugriffe über Bad Bots
4. Extrem viele Besucher

Bei dir, wenn ich mir die eine Seite anschaue würde ich eventuell auf eine schlechte Konfiguration tippen, beim Aufruf der Seite (hab nur grob geschaut ohne das richtig zu analysieren muss jemand genauer anschauen) werden 68 JavaScripts geladen, dass ist schon ein wenig viel.

Das der Shop selbst das Problem ist glaube ich nicht, dann hätten wir wir hier einen Ansturm von Meldungen das Hoster ausflippen, daher wird es mindestens einer dieser Punkte sein.


Das hier unten am Ende der config Datei einfügen dann hast du das grobe schon mal ausgesperrt so das die keine unnötigen Ressourcen fressen.

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

Vielen dank für die Anhaltspunkte.
Den Punkt mit der Shop Konfiguration werde ich mir auf alle Fälle gleich mal anschauen bzw. weiterleiten.

Danke auch für den Code, werde ich auch einbauen.
Nur damit ich hier auf Nummer Sicher gehe: Mit der config Datei meinst du die includes/config.JTL-Shop.ini.php, oder?

 

[css-umsetzung]

ja genau die meine ich, ich kann m ir aber den Namen nie merken, daher schreibe ich immer nur config Datei

 

[tresor-online]

perfekt, danke!
Jetzt muss ich aber noch fragen, wenn ich schon Code, den ich nicht verstehe in meinen Shop einbaue: 😅
was macht der Code genau?

 

[mh1]

Das hier unten am Ende der config Datei einfügen dann hast du das grobe schon mal ausgesperrt so das die keine unnötigen Ressourcen fressen.

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

Und wenn man diesbezüglich noch ein bisschen mehr an der Performance Schraube rumspielen will, könnte man solche Dinge direkt vom Webserver machen lassen, damit die Bots ihr 403 schon kriegen, bevor die Anfrage auf den PHP Prozess trifft. Also im Falle von Apache die Regeln direkt in die httpd.conf oder wenn man da nicht drankommt in eine .htaccess schreiben.
Noch besser wäre diese Regeln schon in der Firewall zu haben, damit die Bots schon abgewiesen werden, bevor die Anfrage auf dem Webserver aufschlägt. Aber vermutlich hast du in deinem Tarif gar keinen Zugriff auf die Firewall.

 

[css-umsetzung]

Das habe ich damals erstellt als Shops durch Bots lahmgelegt wurden, es schaut auf den Useragenten und wenn das was da steht drin vorkommt dann wird der Shop gar nicht erst aktiv

zu mh1:
ich bin da anderer Meinung, weil die .htaccess bei jedem Zugriff schauen muss ob es eine Berechtigung gibt. Aber das muss jeder für sich entscheiden.

 

[tresor-online]

also bezüglich httpd.conf müsste ich bei meinem Host nachfragen, ob das geht, oder?
ob der Einbau in .htaccess oder config Datei besser ist lass ich euch ausdiskutieren, da kenn ich mich nicht aus ^^

 

[bbfdesign]

Moin
Zitro Hosting hat einen Badbot Schutz über seine Server aufgespannt und schützt so alle Kunden in seinem Hosting. Hier mal die Auswertung:

https://badbots.zitro.black/

Gruß Björn

 

[css-umsetzung]

An die hhtp conf wirst du nicht herankommen und die werden die für dich auch nicht ändern.

Ich bin gegen die htaccess, weil der Apache mit jedem Aufruf, den ein regulärer Kunde macht, prüft ob er das darf, daher ist das für mich eher ein Performancekiller als ein php Process denn,
der gleich nachdem er gestartet wurde wieder beendet wird, denn letztendlich möchtest du ja nur die Last verringern die der Shop verursacht die die ganzen Berechnungen zum rendern der Seiten und die vielen SQL Querys verursachen.

Aber das muss wirklich jeder für sich entscheiden und in deinem Fall ist es ja noch die Frage was dein wirkliches Problem ist.
Das hier ist ja nur eine der vielen Möglichkeiten die ich eben, neben der Überprüfung der Konfiguration zuerst in Angriff nehmen würde.

 

[tresor-online]

Alles klar. Nochmal danke! Ich hab es jetzt auf alle Fälle mal in die config.ini eingebaut, nutzt es nix, schadet es nix
Konfiguration ist als nächstes drann.

Eine allgemeine Frage:
wir haben ja jetzt nach dem update zur Zeit Shop 5.1.5 und PHP 7.4
Könnte ein update auf Shop 5.2 und PHP 8.1 auch diesbezüglich einen positiven Effekt haben? Muss hier aber noch alle plugins prüfen, ob die bereit sind.

 

[css-umsetzung]

Könnte ein update auf Shop 5.2 und PHP 8.1 auch diesbezüglich einen positiven Effekt haben? Muss hier aber noch alle plugins prüfen, ob die bereit sind.

Nein, der 5.1.5er kann max. php 8.0, insofern man Plugins am laufen hat die Ioncube verschlüsselt sind muss man dann zwingend bei php 7.4 bleiben.
der 5.2.x kann derzeit "nur" php 8.1

 

[tresor-online]

Ja, das ist soweit schon klar.
Aber gesetzt dem Fall, dass alle Plugins ohne ioncube laufen?
Dann könnte ich doch auf 5.2/8.1 wechseln oder?
Würde aber keine Vorteile in dem Fall bringen?

 

[css-umsetzung]

Wenn du gleichzeitig auf 5.2 wechselst und alle Plugins kompatibel sind dann ja, das solltest du aber vorher mit solution klären, ich meine ich hätte bei dem Shop den ich angeschaut habe ein solution Template gesehen.

 

[tresor-online]

Jap, ist richtig, wir verwenden das esyTemplate.
Von dem her würde es auch gehen.
Aber die ganzen Plugin-Hersteller muss ich noch klären, bei den meißten weiß ich, dass sie PHP 8.1 ready sind, also ohne ioncube, aber die Bestätigung hab ich noch nicht von allen.
Aber gut, eins nach dem andern, erstmal schauen, dass alles gut läuft.

 

[mh1]

Das habe ich damals erstellt als Shops durch Bots lahmgelegt wurden, es schaut auf den Useragenten und wenn das was da steht drin vorkommt dann wird der Shop gar nicht erst aktiv

zu mh1:
ich bin da anderer Meinung, weil die .htaccess bei jedem Zugriff schauen muss ob es eine Berechtigung gibt. Aber das muss jeder für sich entscheiden.

Ich denke, wir sind da gar nicht so sehr anderer Meinung. Denn ich bin auch kein Freund von Overrides. Wenn ich aus irdendeinem Grund den Apache als Webserver einsetzen muss, verziche ich auf den Gebrauch von .htaccess Dateien und baue Regeln lieber in die httpd.conf, denn die wird nur einmal beim restart oder reload gelesen.
Ich wollts nur erwähnen, da es in dem Thread darum ging, den PHP Prozess zu entlasten (hier php-fpm).