php Prozesse erzeugen hohe Serverlast - technische Frage zur Arbeitsweise von Gambio

Die Anfrage geht eher direkt an die Kollegen von Gambio, aber ich dachte ich stelle sie mal im Forum, dass alle was davon haben.

Ich habe einen Kundenshop (übernommen) mit ungewöhnlichen Verhalten. Eckdaten:

• Version 4.3 - von mir komplett neu installiert, da der erste Verdacht ein Fehler nach einem fehlgeschlagenen Update war
• Keine externen Extra Module, wenige mitgelieferte Moduke, nichtmal Google Service wird verwendet
• Zahlunsabwicklung in Vorkasse und PayPal, nicht über den HUB, sondern via Module bei Sonstiges
• Relativ große Datenbank mit vielen Produkten, aber eigentlich mit 1 GB noch im Rahmen

Der Shop läuft ganz ordentlich, aber mehrmals im Jahr kommen neue "Kollektionen". Auf die stürzen sich die Kunden. Die gehen z.B. 19 Uhr online und da stehen schon etwa 100 - 200 Kunden und kaufen direkt alles leer.

Das erzeugt massig einzelne php-prozesse die sich beim Erreichen des Maximums dann gegenseitig blockieren. Damit wird die Serverlast (zwischenzeitlich weit über 50 % CPU Auslastung bei 24 Kernen) massiv hoch getrieben. Hinzu kommt, dass natürlich einzelne Kunden den Shop nicht mehr laden können.

Im Normalfall bewegt sich die CPU Last des betreffenden Servers bei weit unter 10 %.

Zwei Dinge fielen dann gestern in der Prozessüberwachung auf:
1.) neben den massig php-Prozessen ging auch die Auslastung von mysql (mysqld Command) kräftig nach oben
2.) Nach etwa 40 min Ansturm (zwischendurch wurde der Shop von mir immer wieder kurz via CHMOD abgeschalten um die Last soweit runter zu bringen, dass einzelne Bestellungen durch gehen und die User das Schlachtfeld verlassen) ging die Last plötzlich kräftig nach unten. Die Zahl der Bestellungen blieb fast gleich.

Ich habe andere Shops auf gleichen Servern laufen, die haben 3-4 mal mehr Besucher und auch viele Bestellungen pro Tag. Da geht die Last nie auch nur ansatzweise so hoch.

Nun stehen im Verdacht bzw. habe einige Theorien:

1. Die Abwicklung über die Shopinternen Module zur Zahlung. Eine große Menge an API Anfragen an PayPal von der gleichen IP gibt ggf. einen Timeout bei PayPal und der Shop versucht es immer wieder (oder zumindest mehrfach) um blockiert so das Beenden des php-Prozesses.
   Ich kann leider nicht einschätzen wie Gambio in diesem Modul arbeitet. Ich vermute aber, dass via HUB, sollte das ein Problem sein, das Problem keines mehr wäre
2. Gambio wirft so mit Datenbankabfragen um sich, dass wichtige Tabellen, Spalten oder Zeilen gelockt werden - wie arbeitet Gambio da? Slow-Query-Log ist leider keins vorhanden.
3. Einzelne Sessions (Page Token System ist deaktiviert btw) blockieren sich gegenseitig, weil diese lange ausgeführt werden und im Code erst spät geschlossen werden
4. Der Cache ist schuld - Nutzer wartet und lädt ständig die Seite neu. Shopbetreiber schaltet Produkt frei und nun sind zwei Cachedateien unterwegs, weil der Cache nicht sofort geleert wurde. Die Abfragen der Cachedateien bringt Konflikte mit sich und blockiert das Beenden von php-Prozessen
   Das würde einige dieser Logmeldungen erklären:

Code:

www.orange-raven.de 0 2.247.246.131 - - [29/Nov/2021:15:31:10 +0100] "GET /public/theme/styles/system/modules/3c8a4d59169aa5eaca067f480a11b349_additional2.scss HTTP/2.0" 404 311 "https://www.orange-raven.de/?cat=c5_orange-raven-Eigenproduktion-orange-raven-Eigenproduktion.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1"
www.orange-raven.de 0 2.247.246.131 - - [29/Nov/2021:15:31:10 +0100] "GET /public/theme/styles/system/modules/3c8a4d59169aa5eaca067f480a11b349_additional1.scss HTTP/2.0" 404 289 "https://www.orange-raven.de/?cat=c5_orange-raven-Eigenproduktion-orange-raven-Eigenproduktion.html" "Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1"

Bin mal auf euren Input gespannt. Kein ganz alltägliches Verhalten. Bin gespannt was am Ende zur Lösung führt. Nächter Schritt ist sicher das Update auf 4.4 um die Datenbankabfragen noch etwas runter zu bekommen (erinner mich, dass bei 4.4 da dran gearbeiter wurde) und es wird mal testweise auf Gambio HUB umgestellt.

Und ja: Ich weiß dass der SEO Boost nicht aktiv ist. Habe die Kundin mit ihrem Problem frisch übernommen.

 

Die Artikelstruktur könnte defintiv noch sein. Werde, sobald die Kundin sich meldet, mal ein Ticket aufmachen.

Sie hat extrem viele Artikel (wobei das andere Kunden auch haben). Sie hat aber dazu noch massig Artikel in die TOP gepackt. Das ist ein Unterschied zu den meisten anderen. Auch ist die Datenbank etwas größer.

Kategorien sind nicht so tief verschachtelt. Da hab ich schon schlimmeres gesehen.

 

Ich weiß nicht, ob das bei eurem Problem weiterhilft, in unserem Shops hat es bei einem ähnlichem Problem geholfen in der Suche "Suche in Artikelattributen/Artikeleigenschaften" zu deaktivieren

 

Hilft bei dem Problem leider (wahrscheinlich) nicht weiter. Ja die Suche in Attributen und Eigenschaften kann kräftig Leistung ziehen. In diesem Fall nicht der Fall weil deaktiviert. Trotzdem danke.

Nach dem letzten Gambio Stammtisch gehts mal noch eine Runde übers Ticket. Mal schauen...viele Augen sehen mehr.

Update auf 4.4 und Änderungen Zahlungsmodul auf HUB haben jedenfalls keine Änderung gebracht. Sehr mysteriös bisher.

 

Hast Du einen Link zum Shop für uns Rico?

Grüße
Walter

 

Wir haben ein ähnliches Verhalten beobachtet, nachdem wir z.B. einen Newsletter versendet haben. Besonders schlimm war es wenn auf dynamische Seiten wie /products_new.php oder Suchanfragen wie /advanced_search_result.php?categories_id=0&keywords=SUCHWORT&inc_subcat=1 zugegriffen wurde.
Nach Rücksprache und Analyse durch unseren Hoster kam heraus, dass die Artikelbilder für die Überlastung und 500er zu Fehlern geführt haben.
Wenn ich das richtig zusammen bekommen, lag es daran, dass der Abruf von Bildern so viel Last erzeugt hat wenn z.B. bei neuen Artikeln 60 Artikel waren oder bei Suchanfragen noch mehr Ergebnisse geliefert wurden.

Früher sind so vorgegangen: Hochaufgelöste Fotos bei Artikeln eingestellt, diese wurden durch Gambio verarbeitet und zu popup_images, info_images usw. angepasst. Als das fertig war, haben wir das Originalbild komprimiert und per FTP nach original_images hochgeladen.
Das hat dazu geführt, dass diese ganzen kleinen Bilder aber bei der Auslieferung so viele Prozesse und Datenmengen gezogen haben, dass eben nach wenigen Besuchern in kurzer Zeit Schluss war. Gerade bei den dynamischen Seiten (/products_new.php) werden also PHP Prozesse für die Darstellung genutzt der neuen Artikel und Last durch "schwere" Bilder erzeugt.
Nachdem wir kategorisch alle nicht original_images nachträglich komprimiert und wieder hochgeladen haben, hat sich das Problem von alleine gelöst.

Jetzt machen wir es anders: komprimieren die originalen Fotos vor dem Hochladen so, wie wir sie brauchen. Haben in den Einstellungen -> Bildoptionen -> Bildqualität -> 100 eingestellt. Dadurch werden die kleineren Bildchen nicht nochmal komprimiert. Ergebnis: keine Abstürze mehr, weniger Speicherverbraucht auf dem Server, schnellere Ladezeiten.

 

Also wenn Gambio in den letzten Jahren nichts an den Bildern geändert hat, ist das was du da schreibst unmöglich. Irgendwo hier im Forum gibt es eine Erklärung, ich glaub von Wilken wie die Bilderstellung funktioniert.

 

In diesem Fall nicht öffentlich. Hab dich mal über den üblichen Kanal was geschickt.

Dass die dynamischen Seiten etwas rechenintensiver sind, ist richtig. Auch wenn man z.B. bei Kategorien einstellt, dass viele Produkte angezeigt werden, kann das etwas mehr Ladezeit verursachen.

Was du da aber mit den Bildern schreibst erscheint mir unlogisch. Die "original_images" werden eigentlich nur als Link hinterlegt und nicht mehr durch den Shop selbst genutzt. Der nutzt die Thumbnails, Info_images und Popup_images. Sieht man schön, wenn man in der Produktansicht beim Bild mal rechte Maustaste erst auf "Link in Tab öffnen" und dann auf "Bild in Tab öffnen" geht. Das Bild ist info_images und der Link ist das Originalbild. Beim Klick geht dennoch die Lightbox auf und es wird das popup Bild angezeigt. Das ist SEO-Technisch auch sinnvoll, weil sich Google dann im Idealfall das Originalbild zieht. Das Bild hochzuladen, dann das Image Processing laufen zu lassen und dann das Orignialbild nochmal via FTP zu ersetzen ist allerdings allgemein einfach Unsinn. Wenn das Originalbild dann z.B. 2 MB groß ist, kann das durchaus einiges an Ladezeit verursachen, sobald die Bilder abgecrawlt werden. Das hat dann aber nichts mit den kleinen Bildern zu tun. Was für ein Hosting habt ihr denn bei profihost gebucht? Das Shophosting?

Was du dort schreibst, dass die kleinen Bilder so viele Datenmengen gezogen haben, erschließt sich mir einfach nicht. Sorry, aber das ergibt keinen echten Sinn, auch wie ihr das macht bzw. gemacht habt. Entweder drückst du dich da verkürzt oder unglücklich aus oder das Problem lag woanders.

Die kleinen Bilder werden dennoch beim Hochladen in den Artikel erstellt. Bei 100 wird eben weniger komprimiert.

Und Fehler 500 hieß ja einfach nur, dass der Server ausgestiegen ist. Trotzdem Danke für den Input. Hatte schon Server, wo riesen Datenmengen shared hosting Tarife in die Knie gezwungen haben. Da sah das Fehlerbild aber anders aus.

 

Schau dir die Bildgrößen mal im Ordner an, dann wirst Du feststellen dass die kleineren Bilder gar nicht komprimiert und somit fast doppelt so viel KB brauchen wie die komprimierten originale.
Dazu gibt es auch einen eigenen Beitrag hier.

Was aber helfen kann ist, wenn man für die Kacheln (Startseite und Kategorien) die kleineren Thumbnails nimmt und nicht die
großen Info-Bilder

 

Evtl. habe ich das verwirrend erklärt.

Früher:
Original-Bilder unkomprimiert hochgeladen. Thumbs etc. wurden daraus unkomprimiert erstellt und überall im Shop eingesetzt. Weil vor Upload keine Kompression bei Originalbildern -> Thumbs etc. entsprechend größer als sie sein müssten. Bei dynamischen Seiten mit Duzenden Artikeln = höhere Last bei gleichzeitigem Zugriff auf PHP Slots, Ram, CPU. Bei uns waren das schon mal um die 100 in /products_new.php

Nach Rücksprache mit unserem Hoster / jetzt:
Wir komprimieren alle Bilder vor dem Upload selbst, d.h. alle Thumbs und Co. die daraus generiert werden, haben automatisch auch geringere Größen. Server/Webspace hat nach wie vor die gleichen Ressourcen, aber weniger Nutzung von memory_limit oder sehr wahrscheinlich auch der PHP Slots. Der gesamte Abruf einer Seite pro Besucher geht schneller, weil weniger Daten verarbeitet werden müssen. Das war zumindest die Quintessenz unserer Auswertung und erst als wir die Bilder anders einsetzen, haben sich diese Probleme gelöst.

Kurzum (so wie ich das verstanden habe): Kleinere Dateigrößen aller Bilder = weniger 5xx Fehler bei höheren Besucherzahlen, da memory_limit weniger "Gewicht" abzuarbeiten hat = PHP Prozesse bekommen kein timeout.

Man muss dazu sagen, dass wir ca. 70-80% Dateigröße der original_images mit der fast verlustfreien Kompression einsparen. Alle Bilder, die im Shop dann entsprechend aus diesen Originalen erstellt werden, sind auch deutlich kleiner (ca. 30-40% als ohne die Kompression).

 

falsch.
Schau mal ab hier:
(Link nur für registrierte Nutzer sichtbar.)

soweit ich weiß hat sich da nichts geändert.

Das kann dann natürlich zu weniger Auslastung führen, weil deutlich weniger geladen werden muss.

Nehmen wir man das Bild hier:
speznas-5-elements-bracelet-c9155340-5130d-1.jpg

das hat als info_image = 220kb


als original_image aber nur 86kb


Das info-Bild im Artikel, welches vom Shop erstellt wurde, hat also fast 3x so viele KB wie das viel größere Original

 

Hallo Barbara, oder auch anderer Spezialist hier, ich hatte das Thema auch schon öfter angesprochen, das die Miniaturbilder teilweise eine Größe von 150-300 kb haben. Kann man dies nicht einfacher gestalten ? Das Original Setup sollte doch wenigstens so eingestellt sein das es nicht größer ist als das Originalfoto. Normal reicht für ein kleines Bild 50kb Größe, da ist man schon bei einer guten Qualität.

 

In diesem Fall hast du Recht, weil wir noch ca. 300 Artikelbilder nicht final überarbeitet haben. Die Zeit fehlt dafür, bei über 4800 Bildern, die hinterlegt sind. Bei den alten Artikeln hole ich mir die Unterordner aus product_images und jage die Bilder stapelweise durch die Kompression. Geht schneller als per Hand bei allen Artikeln neue, komprimierte original_images Bilder hochzuladen.

Habe gerade mal das info_image aus dem Beispiel oben komprimiert und hochgeladen:


Und beim thumbnail_image:


Das Thumb ist aber auch das relevantere von beiden beim Abruf einer Kategorie oder /products_new.php
Info und Pop-up gehen erst auf der Artikeldetailseite los, aber die Anzahl der Zugriffe (zumindest in unseren Fällen beim Newsletterversand usw.) gehen erst einmal auf die Kategorien, Suchanfragen und neue Artikel.

Wir nutzen übrigens https://www.iloveimg.com/ für die verlustfreie Kompression. Uns haben TinyJPG, JPEGMini, Caesium Image Compressor nicht überzeugt: entweder zu viel komprimiert oder Dateigröße noch zu groß.

 

So geht das, aber der Shop selber macht das nicht.
du wirst also immer Bilder in allen Größen selber komprimieren müssen.
Ich denke alles weitere zu Bildern solle in dem anderen Beitrag geführt werden, das kapert hier zu sehr das eigentliche Thema.

 

Ich weiße an der Stelle zwecks Bildoptmierung mal freundlich auf jpegoptim und optipng unter Linux hin.

find . -name "*.jpg" -exec jpegoptim {} +
find . -name "*.png" -exec pngcrush {} + (sofern man PNG hat)

Geht allerdings nicht bei jedem Hoster. Ist klar. Braucht das installierte Programm und die entsprechenden Rechte via SSH.

Backup der Bilder empfehlenswert...der geht damit über alle Bilder drüber, außer man schränkt das Verzeichnis noch ein.

 

Mal weiter hier, weil bisher die Ursache noch nicht gefunden wurde, obwohl ich echt schon viel ausprobiert habe.

Es scheint im Moment als wenn tatsächlich die Artikelübersicht die vielen Prozesse auslöst. Ich konnte es noch nicht morgens testen, wenn der Shop wenig bis keine Besucher hat und dafür offline genommen habe ich ihn auch nocht nicht, aber scheinbar kann ich die Prozessmenge simulieren, in dem ich mit verschiedenen Clients die Hauptkategorien aufrufe.

Verdacht geht gerade dahin, dass es die Artikelbestandsprüfung ist. Allerdings folgt aus einer Deaktivierung kein Ende der massig Prozesse, die durchgeführt werden. Und andere Shops haben die Prüfung ja auch. Wie ich darauf komme? Aus den Zugriffslogs sieht man, dass immer beim Aufrufen der Kategorienseiten mit vielen Artikel dieser GET direkt x-mal nacheinander auftaucht:
"GET /shop.php?do=CheckStatus/Attributes&products_qty=5&products_id=2839&target=check&isProductInfo=0&page_token=&_=1639250081028 HTTP/2.0" 200 1325 "https://www.***/?page=7" (nicht nur Page=7, auch alle anderen oder auch ohne Page)

Die qty=5 dürfte sich aus der Meldeschwelle für die Nachbestellung erklären. Obs das wirklich ist, keine Ahnung. Andere Shops haben diese Prüfung ja auch. Warum aber die Prüfung von den Kategorienseiten ausgelöst zu werden scheint....pffff.

Und nein lieber Gambio Support. Die Antwort "solange die vielen PHP Prozesse nicht den Shop lahmlegen und dieser weiterhin nicht unter den vielen Prozessen zusammenbricht, ist die große Anzahl der PHP Prozesse kein Problem." ist keine befriedigende und nützliche Antwort. Ein Shop der es schafft mit <200 gleichzeitig online seienden Nutzern einen 24 Kern Server massiv auszulasten, hat ein Problem. Defintiv.

 

Update:
Habe jetzt mal in einem gesonderten Container einen komplett sauberen Testshop eingerichtet und nur per CSV die Artikel und Kategorie rüber exportiert/importiert. Selbst die Bilder sind nicht vorhanden.

Die GET Abfrage nach dem Bestand habe ich wegbekommen indem die Mindestbestellmenge von 5 auf 1 gesetzt wrude (alle Produkte). Änderung bei der Prozessanzahl nicht sichtbar. Ist also nicht das Problem.

Aber: In diesem Testshop ist genau ein Nutzer online. Ich. Nur durch das Aufrufen der Startseite (Slider der Produkte) und der Kategorienseiten konnte ich allein (ganz allein) ad hoc zwischen 15 und 20 PHP-Prozessen erzeugen. Habe ich direkt 196 Artikel anzeigen lassen, waren es geschätzt 30-40 (so schnell konnte ich weder Zählen noch Scrollen).

Offenbar erzeugt das Anzeigen der Artikel (der Artikelbilder?) so viele Prozesse. Warum? Shopversion bei beiden 4.4.0.2

Heute hab ich erstmal keine Lust mehr. Eventuell teste ich nochmal mit einer 4.0 ob das da auch so ist...

 

Bilder sind normal statische Assets, es sei denn die skalierten Bilder fehlen und lösen so einmalig pro Bild ein Imageprocessing on the fly aus. Für vorhandene Bilder spawned also normal kein PHP Prozess.

Nichtsdestotrotz: Viele PHP Prozesse sehen wir nicht unbedingt als Fehler an, eher als simples Zeichen von zu leistender Arbeit. Das muss also nicht zwangsweise kaputt sein, 30-40 ist aber relativ viel für einen Nutzer.

 

So langsam frage ich mich auch leise, ob ich ein Phantom jage oder einfach nur völlig vernagelt oder zu blöd bin.

Hat mir keine Ruhe gelassen, deswegen heute Morgen eine Testreihe.

Testshop Version 4.4 - Shop offline, ich einziger Nutzer auf dem gesamten Container
Artikel aus Problemshop per CSV exportiert, dort importiert. Kategorieseite aufgerufen, 196 von knapp 600 Artikeln einer Kategorie anzeigen lassen.
Ergebnis: Dutzende php-Prozesse. Beliebig wiederholbar.

Testshop Version 4.0 - Shop offline, ich einziger Nutzer auf dem gesamten Container
Artikel aus Problemshop per CSV exportiert, dort importiert. Kategorieseite aufgerufen, 196 von knapp 600 Artikeln einer Kategorie anzeigen lassen.
Ergebnis: Dutzende php-Prozesse. Beliebig wiederholbar.

Liveshop vom Kunden A aufgerufen, Version 4.2 - Shop online, Ca. 80 Kunden (laut wer ist online) im Shop
Einstellungen der Kategorien vergleichbar vom "Problemshop". Massig Artikel, teilweise >600 in verschiedenen Unterkategorien einer Hauptkategorie, Es werden alle Produkte der Unterkategorien mit angezeigt Eine dieser Kategorien aufgerufen und die Anzeige der Artikel auf "240 auf einer Seite" aufgerufen
Ergebnis: 2 php Prozesse ploppen kurz zusätzlich auf - beliebig wiederholbar. Kaum php-Prozesse

Testshop Version 4.4 - Shop offline, ich einziger Nutzer auf dem gesamten Container
Artikel aus Kundenshop A per CSV exportiert, dort importiert. Kategorieseite aufgerufen, 196 von knapp 600 Artikeln einer Kategorie anzeigen lassen.
Ergebnis: Dutzende php-Prozesse. Beliebig wiederholbar.

Liveshop vom Kunden B aufgerufen, Version 4.1 - Shop online, Ca. 14 Kunden (laut wer ist online) im Shop
Einstellungen der Kategorien ähnlich wie der Problemshop, eine Kategorie mit ca. 100 Artikeln, der Rest deutlich weniger. Diese Kategorie aufgerufen und die Anzeige der Artikel auf "120 auf einer Seite" aufgerufen
Ergebnis: Ein php Prozess ploppte extra auf - sonst alles easy

Servereinstellungen bei allen Shops identisch. Ich verstehs einfach nicht.

Fakt ist nur, dass es ein Problem darstellt, weil der Shop regelmäßig wirklich gute Hardware an seine Grenzen bringt...ohne dass es da eine Nutzerzahl gibt, die das aus meiner Sicht rechtfertigen würde.