Neu Stabilität und Performance optimieren

[lroehrs]

Moin!

Ein Kunde von uns hat Anfang kommende einen TV Auftritt und die ersten Lasttest zeigen bereits, dass der Shop höchstwahrscheinlich dem Ansturm nicht standhalten wird.

Eckdaten:

• Shopversion: 4.06 (Build: 17)
• PHP7.3
  • mit OPcache und APCu
• Web/DB Cluster mit jeweils 32 Kernen

Sämtliche Software ist entsprechend aktuell, Objekt Cache ist aktiv und Sessions werden über Redis gesteuert.
Bei dem Lasttest in dem nur GET Abfragen stattfanden komme ich nicht über ca. 350rps bei nahzue 100% CPU Last auf dem Webserver.
Mit vergleichbaren Shopware Shops sind wir dabei bei mind. 850rps. Jeweils ohne Medien, entsprechend "nur" Seiten-Generierung.

Der JTL Cache habe ich ursprünglich auf Redis gesetzt, getestet jedoch auch auf Disk und tmpfs - kommt alles auf das ähnliche hinaus.
Ohne Last ist der Shop super schnell, da gibt es nichts zu beanstanden.


Bei einer Tideways-Prüfung fiel mir dann auf, dass jeder Aufruf über 20 SQL Abfragen entstehen.
Die Abfragen sind ohne Login o. ä., ich erwarte da eigentlich, dass mehr aus dem Cache beantwortet wird.
Ist das bei JTL so üblich?

Die Datenbankabfragen auf dem Datenbanken-Server fallen auch entsprechend hoch aus.

Hat jemand Tipps oder fällt ggf. noch jemanden eine Fehlkonfiguration auf?

Danke!

 

[hula1499]

Hm, witzige/interessante Beobachtung.

Wir haben/hatten diverse Promotions und in der ersten Stunde dann 10-15k Leute auf der Seite, davon dann rund 60-70% conversions.

Live-Tests/config:
Die CPU langweilt sich und geht nie über 5% (Strato D670, SSD, 64GB RAM)
REDIS
CDN für js/css/Bilder (nimmt natürlich viel Last ab)
ngix / sql voll auf RAM getrimmt (der geht dann aber auch auf ~90%)

An den Millionen DB Abfragen kannst leider nicht wirklich was machen.

Worauf du dich bei so einem kurzfristigen Ansturm einstellen kannst/musst:
.) nicht unerhebliche Anzahl von Doppelbestellnummern ausm Shop
.) Lagerstand Abgleichsprobleme: da Shop/ WaWi da recht zum stocken beginnen (puffer grosszügig einplanen, Abgleichintervalle runtersetzen)
.) solltest du mit Lagerbestand arbeiten und dieser während der Bestellungen ausgehen, bekommt dein Kunde auch diverse "Leerbestellungen" bedeutet: bezahlte Versandkosten ohne Produkte

 

[FMoche]

Ahoi,

20 SQL-Abfragen pro Seite sind realistisch. Besucherstatistik und ein paar Kleinigkeiten werden immer direkt über die DB gemacht.
Für einen echten TV-Modus macht es aber auch keinen großen Unterschied - da wirst du um HTML-Caching nicht herumkommen.

Ich habe hier noch einen experimentellen Branch rumliegen, der für solche Fälle den Smarty- Cache nutzt und somit die aufwendigste Shoplogik umgeht.
Alternativ bietet sich als schnellste Möglichkeit der FastCGI-Cache an. Damit könnte man dann zumindest die Besucher abfedern, die keine Artikel im Warenkorb haben und nicht eingeloggt sind. Das sollte aber schon helfen.

Meine Testkonfiguration in nginx sieht ungefähr so aus:

upstream _php {
    server unix:/var/run/php/php7.4-fpm.sock;
}

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=JTLSHOP:350m inactive=180m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

server {
    set $skip_cache 1;
    if ($request_method = GET) {
        set $skip_cache 0;
    }
    if ($request_uri ~* "/(warenkorb.php|admin|jtl.php|warenkorb|cart|konto|account)"){
        set $skip_cache 1;
    }
    if ($http_cookie ~* "eSIdAdm|jtl_logged_in|jtl_no_cache|jtl_cart") {
        set $skip_cache 1;
    }

    location ~ \.php$ {
        try_files $uri $uri/ =404;
        fastcgi_pass _php;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache JTLSHOP;
        fastcgi_cache_valid 200 60m;
    }
}

Dazu dann ein Mini-Plugin, dass sobald ein Artikel in den Warenkorb gelegt wird den Cookie "jtl_cart" setzt und nach dem Login den Cookie "jtl_logged_in".


Hat aber alles seine Grenzen, was die Kompatibilität mit diversen Plugins anbelangt.

 

[lroehrs]

Das ist ja mal echt interessant.

Ich habe mir mal angeschaut, wie die Auslastung entsteht:

[2020-09-11 11:53:11]: FCGI Script: /index.php? Uid: 1001 Utime: 8
[2020-09-11 11:53:11]: FCGI Script: /index.php? Uid: 1001 Utime: 6
[2020-09-11 11:53:11]: FCGI Script: /index.php? Uid: 1001 Utime: 8
[2020-09-11 11:53:11]: FCGI Script: /index.php? Uid: 1001 Utime: 8

grep "2020-09-11 11:53:11" /home/var/log/scripts/fcgi | wc -l
369
grep "2020-09-11 11:53:12" /home/var/log/scripts/fcgi | wc -l
373
grep "2020-09-11 11:53:13" /home/var/log/scripts/fcgi | wc -l
360
grep "2020-09-11 11:53:14" /home/var/log/scripts/fcgi | wc -l
353
-----

Utime = CPU Sekunden * 100
360*0,08=28,8 ~29 Kerne

Das entsteht bei ca. 350 Request. Entsprechend ist es klar, dass der Webserver nahezu vollständig ausgelastet ist.
Anhand des Tideways Traces vermute ich, dass es durch Smarty Berechnungen kommt.

Der Nginx Cache Aufbau würden wir wahrscheinlich noch hinbekommen, der Auftritt ist jedoch am Montag.
Das entsprechend Plugin müsste durch den Kunden/Agentur erfolgen, wage etwas zu bezweifeln das es in der Zeit realisierbar ist.

> Ich habe hier noch einen experimentellen Branch rumliegen, der für solche Fälle den Smarty- Cache nutzt und somit die aufwendigste Shoplogik umgeht.
Wo ist der denn zu finden?

 

[FMoche]

So ein Plugin hab ich dir in 2 Minuten mal zusammengedengelt:
https://gitlab.com/felix.jtl/fm_nocache_cookies

 

[Roddi]

So ein Plugin hab ich dir in 2 Minuten mal zusammengedengelt:

Respekt vor so schneller Dengelarbeit...

 

[FMoche]

Den TV-Mode-Branch findest du ansonsten hier:
https://gitlab.com/jtl-software/jtl-shop/core/-/merge_requests/1111/diffs

- der basiert allerdings auf dem bislang nicht releaseden Shop 4.07 - nicht 4.06! Könnte man aber evtl. um-operieren.

 

[lroehrs]

Ich hab mit zwei Partner-Agenturen gesprochen, die folgendes Plugin erwähnten:

https://shop.knoell-marketing.de/JTL-Supercache

Auswirkung:

[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 1
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 0
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 0
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 1
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 1
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 1
[2020-09-11 14:32:03]: FCGI Script: /index.php? Uid: 1001 Utime: 1

grep "2020-09-11 14:32:03" /home/var/log/scripts/fcgi | wc -l
1066
grep "2020-09-11 14:32:04" /home/var/log/scripts/fcgi | wc -l
1116
grep "2020-09-11 14:32:05" /home/var/log/scripts/fcgi | wc -l
1135

Bei einer CPU Last von ca. 65%.


Eine wird sich ggf. den Shop nochmal weiter anschauen, teile ich aber auch das Ergebnis aus diesem Thread mit.
Danke!

 

[juergen-sfx]

...
    if ($request_uri ~* "/(warenkorb.php|admin|jtl.php|warenkorb|cart|konto|account)"){
        set $skip_cache 1;
    }
...

Hat aber alles seine Grenzen, was die Kompatibilität mit diversen Plugins anbelangt.

Ich mache mir da besonders in Hinblick auf Zahlungsplugins Sorgen. Müsste man da nicht die Anfragen z.B. von der PayPal IPN irgendwie ausschließen?
Ich sehe da z.B. in unseren Logs:
/includes/modules/notify.php auf das GET Anfragen abgesetzt werden.

Vielleicht könnte man hier im Thread die URLs sammeln, die man vom Caching ausschließen muss, das wäre toll.

 

[lroehrs]

Vorab, vielen Dank an alle - ich bin überrascht und begeistert von der Unterstützung.
Mein Blick auf JTL ist inzwischen sogar richtig gut.


Der Abend verlief soweit gut, es gab zwar in der zweiten Welle einen temporären Ausfall, mit diesem haben wir jedoch aufgrund der kurzen Vorlaufzeit gerechnet.
Grund des Ausfalles scheint ein Hänger in der Datenbank gewesen zu sein - genaueres Details (Queries etc.) haben wir nicht geloggt und kann ich daher nicht melden.

Neben dem Caching Plugin haben wir noch Cloudflare aktiviert wodurch weniger als 1/4 der Request überhaupt an den Webserver ging.
Unglücklicherweise gab es dafür DNS-Probleme bei der Telekom. :/
Der Webserver war in der Spitze zu 30% ausgelastet.

 

[Rainer S]

Glückwunsch, als Empfehlung da Du Cloudflare erwähnst, hier solltet Ihr den Webshopabgleich von Cloudflare ausschliessen um Abgleichprobleme zu vermeiden, dazu habe ich folgende Anleitung gefunden:

https://www.sfxonline.de/blog/jtl-wawi-jtl-shop-fuer-betrieb-mit-cloudflare-cdn-konfigurieren/

 

[lroehrs]

Glückwunsch, als Empfehlung da Du Cloudflare erwähnst, hier solltet Ihr den Webshopabgleich von Cloudflare ausschliessen um Abgleichprobleme zu vermeiden, dazu habe ich folgende Anleitung gefunden:

https://www.sfxonline.de/blog/jtl-wawi-jtl-shop-fuer-betrieb-mit-cloudflare-cdn-konfigurieren/

Stimmt, danke für die Ergänzung! Wurde bei unserem Kunden durchgeführt, für dritte die das hier lesen aber sicherlich wichtig.

 

[juergen-sfx]

Glückwunsch, als Empfehlung da Du Cloudflare erwähnst, hier solltet Ihr den Webshopabgleich von Cloudflare ausschliessen um Abgleichprobleme zu vermeiden, dazu habe ich folgende Anleitung gefunden:

https://www.sfxonline.de/blog/jtl-wawi-jtl-shop-fuer-betrieb-mit-cloudflare-cdn-konfigurieren/

Heh, das kenn ich irgendwo her

Alternativ kann man auch eine zweite dedizierte IP dafür nutzen. Hat den Vorteil, dass man diese eventuell über einen eigenen php-fpm Pool betreiben kann. Dadurch kann man die PHP Laufzeiten für Shop und Sync getrennt optimieren (Shop kurze Laufzeit um wenig Blockaden zu haben, Sync lange laufzeit.)