Lange Ladezeiten Variantenartikel

Shopware 5 Allgemein
1

Hallo,

das Thema ist schon mehrfach diskutiert worden, aber nirgendwo hat die Diskussion bisher mit einer wirklichen Lösung geendet: Die nicht akzeptable Ladegeschwindigkeit von Variantenartikeln

Im konkreten Fall geht es um einen B2B-Shop eines Texttilherstellers, der Kleidungstücke in verschiedenen Farben (1 bis 8 Varianten) und jeweils acht Größen verkauft, also im Textil- und Schubereich nichts außergewöhnliches. Es gibt also zwei Varianten-Gruppen - Größen und Farben.

Der Shop läuft auf einem Server mit aktuelllem  SUSE-Linux mit PHP 5.6 und MariaDB, aktiviertem Opcache und 12 GB Arbeitsspeicher zusammen mit drei weiteren Anwendungen, darunter ein anderer Shopware-Shop ohne Variantenartikel.

Bei gecachten Artikeln ohne Varianten liegen die Ladezeiten bei 200 bis 900ms, wird eine Detailansicht des Variantenartikels aufgerufen steigen die Ladezeiten auf  4 bis 5 Sekunden. Die gleiche Zeit wird für einen Variantenwechsel benötigt. Ein Caching findet offenbar nicht statt. Da einer erneuter Aufruf einer Variantenkombination keinen Zeitvorteil bringt. Das ist für den Kunden nicht akzeptabel, da seine Einzelhändler von einem Kleidungsstück in der Regel alle Größen-Varianten kaufen. Auch die Ablage in den Warenkorb ist mit ca 2 bis 3 Sekunden nicht sehr schnell.

Die Auslastung von CPU und Arbeitsspeicher sind bei Shopaufrufen gering (meist unter 30%). Allerdings auffällig ist, dass bei Aufrufen von Artikeldetails aus dem Shop die Zahl der Datenbankabfragen schlagartig um ca 300 !!!  steigt, und das bei rechnerich meist 30 bis 40 Variantenkombinationen. Was passiert da im Hintergrund, wo passiert das und geht das nicht einfacher? Hat vielleicht jemand ein Plugin für einen ressourcenschonenden Variantenwechsel. Texte, Preise und Bilder sind aktuell bei allen Varianten identisch.

Auffällig ist noch, dass beim Blick in die Datenbank-Prozessliste ein Prozess des Shops mit einer Sleep-Zeit von 4 Sekunden auftaucht. Leider ist diesem Prozess kein SQL-Befehl zugeordnet.

Hat jemand eine Idee, wie man die Abarbeitung der Datanbankaufrufe ggf beschleundgen kann. Ich habe Zugriff auf my.cnf.

Da es sich um einen geschlossenen B2B-Bereich handelt, kann ich die Url hier nicht veröffentlichen. Ich kann aber Menschen, die sich mit Shopware besser auskennen, einen Zugang einrichten.

Viele Grüße

 

Michael

 

 

 

 

2

PHP auf 7 upgraden (ausgiebig auch mit aktivierten Plugins testen)!

SSD auf Server verwenden

HTTP/2 aktivieren

Wie groß sind die Variantenbilder?

Auch mal das durcharbeiten: http://community.shopware.com/Performance-Tipps-Shopware_detail_1258.html

3

Danke Raymond,

Der Umstieg auf PHP7 incl. Apcu ist geplant, aber wegen des Ioncube-Wahnsinns nicht so einfach. Einer der Shops hat ca 10 gekaufte Plugins, deren Lizenzen neu verschlüsselt werden müssen. Und da hakt es mächtig - aber das ist ein ganz anderes Thema.

Variantenbilder gibt es aktuell nicht, SSD etc würden vielleicht noch einige Prozent bringen, aber aus meiner Sicht ist das ein Herumdoktern an den Symptomen, aber beseitigt die eigentliche Ursache nicht: Beim Aufruf von Variantenartikeln und beim Variantenwechsel gibt es dringenden Optimierungs Bedarf. Schön wäre es schon, wenn es ein Plugin gäbe, dass beim Wechsel der Variante nur die Artikelnummer (sowie weitere für das Legen in den Warenkorb ggf notwendige Daten) aktualisiert, also Bilder, Texte etc nicht abfragt und akualisiert.

Immerhin dauert das Laden eines Artikel mit 28 möglichen Variantenkombinationen mindestens 5- bis 20-mal so lange wie ein Artikel ohne Varianten. Schlanke Artikel liefert der Server in 200ms.

Die verwende SW-Version ist übrigend 5.2.27.

Viele Grüße

 

Michael

 

4

Hallo miloy,

wennn man alle Shopware-Caches löscht, dauert das erste Laden einer Variante (der erste Variantenwechsel) lange. Es wird ungefähr die identische Zeit benötigt wie beim ersten Laden eines “Stammartikels”. Alle weiteren Variantenwechsel benötigen dann ungefähr dieselbe Zeit wie das Laden des Stammartikels (Bearbeitungsmodus). Wenn das Aufrufen des Artikels 300ms dauert, benötigt das Wechseln zu einer Variante ebenfalls ~ 300ms. Auf keinen Fall das vierfache oder mehr. Die Ladezeit von 3-4 Sekunden kann beim allerersten Aufruf einer Variante auftreten, danach nicht mehr. Und für diese Zeiten benötigst Du keinen dedizierten Server, das bekommst Du auch mit einem virtuellen Server hin. 

Hast Du Plugins im System, die dies verlangsamen? 

Um die obigen Zahlen zu erreichen, brauchst Du eigentlich auch keine spezielle Datenbankkonfiguration. 

Die SSD beschleunigt das System auf jeden Fall spürbar, zumindest im Vergleich zu einer Sata-HD, das ist schon ein vernünftiger Tip gewesen. 

5

Hallo,

schön wäre es, wenn es so wäre wie du schreibst, aber leider scheinen Variantenartikel nicht gecached zu werden (Frage: Kann man das irgendwie überprüfen?). Während sich bei Kategorieansichten oder Artikeln ohne Varianten die Ladezeiten beim zweiten Aufruf auf ein Fünftel bis ein Zehntel (Je nach Bildumfang, Texten) von ca 3 bis 4 Sekunden auf 200 bis 900ms verkürzen, verharren die Variantenartikel bei über 4 Sekunden - das gilt für den Stammartikel und den Variantenwechsel gleichermaßen.

Michael

6

Wenn die Plugins irgendwann Shopware 5.3 kompatibel sind (Plugin Anbieter anschreiben!) dann darauf updaten. Hier wurde gut an der Performance gearbeitet: https://de.shopware.com/neuheiten/ (sehr weit unten)

1 „Gefällt mir“
7

SSDs oder sogar NVMe-Platten bringen auf jeden Fall etwas, gerade für Datenbanken. Außerdem würde ich Dir empfehlen, einmal Deine MySQL-Konfiguration zu prüfen, z.B. mit mysqltuner.pl: https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de

1 „Gefällt mir“
8

Hallo,

also MariaDB ist optimiert, der Shop ist auf die aktuellste Version upgedated. Die Performance-Verbessungen bei gecachten Seiten sind super, die Reaktionszeit liegt jetzt bei 50ms.

Allerdings bei den Variantenartikeln ist die Verbesserung eher marginal - 4,3s statt 4,7s.

Mir ist bei den wiederholten Tests aufgefallen, dass das Caching der Variantenartikel offenbar nicht oder nicht optimal funktioniert:

Beispiel
Ein erster Kunde ruft die Artikeldetails des Stammartikels Nr 100 auf - Ladezeit 4,3 Sekunden. Der Kunde ruft keine Varianten auf.
Ein zweiter Kunde ruft die Artikeldetails des Stammartikel Nr 100 auf - Ladezeit ca 120ms. Der Artikel ist offenbar im Cache.
Der zeite Kunde wechselt die Variante der Artikels auf Farbe blau und Größe 40 - Ladezeit des Wechsel 4,3s ->  Die Artikelnummer ändert sich auf 100.15
Ein dritter Kunde ruft die Artikeldetails des Stammartikels Nr 100 auf - Ladezeit wieder 4,3 Sekunden. Der Artikel ist offenbar nicht mehr im Cache (wahrscheinlich liegt dort unter der Artikelnummer 100 jetzt der Artikel 100.15).

Nimmt man nämlich die Url einer geladenen Variante und ruft sie von einem anderen Browser aus auf, hat man wieder eine kurze Ladezeit - offenbar weil die Variante gecached worden ist.

Wenn ich es richtig sehe, wird pro Artikel entweder der Stammartikel oder eine seiner Varianten gecached. Deshalb führt jeder Variantenwechsel zu den langen Ladezeiten. Die Lösung wäre vermutlich das (optionale) Cachen aller Varianten. Das wäre bei meinem Shop mit nur rund 50 Artikel mit jeweils 30 Varianten - also dann 1500 gecachten Seiten - kein Problem.

Michael

 

 

 

 

 

 

 

 

9

Wir haben exakt gleiches Problem. Der erste Wechsel zwischen Varianten (andere Produktfarben, pro Bild im Schnitt 130kb) dauert zwischen 4 und 5 Sekunden. Erneurter Wechsel geht fix, also unter 1 Sekunde.

Wir stehen mit Shopware Support in Kontakt um das Problem der Ladezeit zu reduzieren. Wie ich das jedoch sehe, liegt der Fehler darin das Shopware die Varianten nicht cached. Da nützt auch eine Optimierung nichts.

Habe das Ticket Issue: SW-19711 gesehen. Hoffe das wird seitens Shopware mal angegangen. Grüße

10

Wir haben ein ganz ähnliches Problem. Bei uns im Shop wird der Cache 4x pro Tag geleert. Wenn man nach dem Leeren des Cache nun einen Artikel aufruft, dauert dieses dann ca. 2 Sekunden, was noch erträglich ist. Beim erneuen Aufruf, hat er den Artikel dann ja im Cache und der erneute Aufruf klappt dann sehr schnell (unter 0,5 Sekunden). Wählt man einige der Varianten dieses Artikels an, dauert es bei einigen Varianten dann auch wieder gut 2 Sekunden bei einigen aber um die 7 Sekunden. Das ist natürlich viel zu langsam. Beim Erneuten Aufruf ist die Variante dann wieder binnen einer gefühlten halben Sekunde geladen, weil er diese dann anscheinend im Cache hat. Wir können uns nicht erklären, warum einige der Varianten beim 1. Aufruf ca. 2 Sekunden brauchen und andere wiederum ca. 7 Sekunden. Es sind auch immer die selben Varianten die extrem lange brauchen. Das Ganze geschieht also nicht zufällig. Auffällig ist, dass die Varianten, die sehr lange brauchen, oft von anderen Artikel verlinkt sind bei “Kunden kauften auch” oder “Kunden sahen sich ebenfalls an”. Kann das eventuell etwas damit zu tun haben, weil in der mySQL viele Verweise auf diesen Artikel sind?

Gruß

Andy

11

Ich habe mich dem langsamen Laden von Varianten immer und immer wieder beschäftigt. Das Thema wurde ja schon häufiger behandelt, aber wie @miloy‍ ja schon sagt, es ist nie in wirklich brauchbaren Ergebnissen oder Lösungen geendet. 
Wir haben einige komplexe Variantenartikel und einige einfache. Mal geht es einigermaßen erträglich schnell, manchmal dauert es selbst bei eindimensionalen Varianten mit nur zwei Versionen bis zu 11 Sekunden! (Gerade eben getestet). In dem konkreten Fall gibt es auch nur 1 Produktbild für beide Varianten. 

Wir haben übgrigends einen Server echtem ngix Hostung, 16GB RAM und NVMe-Platten von @TimmeHosting‍ - nicht shared!. Hatte mir vor dem Wechsel Hoffnungen gemacht es könnte dadurch besser werden, aber leider hat das nichts geändert. Alles andere ist zwar spurbar schneller geworden, die Ladezeit der Varianten hat sich aber nicht verbessert. Mir ist einfach völlig schleiherhaft warum es manchmal so schnell ist und manchmal so uneträglich lange dauert. Wie gesagt, in unserem Fall völlig unabhängig davon ob es ein sehr einfacher Variantenartikel ist oder ein komplexerer mit mehreren Dimensionen und vielen Produktfotos. 

12

@motorg guck mal ob die langsam ladenden Varianten alle einen ab-Preis besitzen und die schnell ladenden nicht…

1 „Gefällt mir“
13

@BestShopPossible schrieb:

@motorg guck mal ob die langsam ladenden Varianten alle einen ab-Preis besitzen und die schnell ladenden nicht…

Tatsache!!! Mit ab Preis = ~ 12 Sekunden. Ohne ~ 2 Sekunden. !!??  

14

Nachtrag: Das hat jetzt natürlich meine Neugierde geweckt. Musste aber feststellen, dass bei dem Artikel ohne „ab Preis“ die zweite Variante nicht aktiv war. Deshalb ist es dann einfach wieder auf die erste Varianten zurück gesprungen, was natürlich schnell ging. Ist die zweite Variante aktiv dauert es wieder die üblichen ~ 11 Sekunden. Selbst wenn beide Varianten einen identischen Preis haben und es somit keinen „ab Preis“ gibt, dauert es so lange. Schade… 

15

Dann hab ich keine Idee mehr außer die Cache Warmup Funktion zu prüfen und zu gucken wie man das abändern müsste, damit auch Varianten greifen.

Muss aber nicht daran liegen, kann auch an der Varianten-Wechsel-Funktion liegen (wohl eher nicht). Kann auch an was ganz anderem hängen. Da muss man nun debuggen, eine Lösung entwickeln und auf Github anbieten oder warten bis das Ticket durch ist oder jemand anderes diesen Thread liest und in 2 Monaten ein verschlüsseltes Plug-In dafür herausbringt.

16

Bei mir werden die Varianten gecached.

1 „Gefällt mir“
17

@NextMike schrieb:

Bei mir werden die Varianten gecached.

Dann rückt ein Plug-In oder gar eine Kombination in den Kreis der Verdächtigen. 

18

Wie gesagt, ich habe mich schon oft und lange mit diesem Problem beschäftigt. Ich habe auch in der Staging Umgebung alle Drittanbieter Plugins deaktiviert. Dies hatte keinerlei positive Auswirkung auf die Ladezeit der Varianten-Artikel. Ebenso wenig wie das Upgrade eines shared Hosting mit normaler Performance zu einem eigenen Server mit viel performance und NVMe Platten. Ich glaube eher es ist ein Problem von Shopware. 

19

Die Variantendaten werden via Ajax geladen (wenn man es nicht abstellt). Das Caching macht wohl nur der Browser aber nur solange man in der Artikelansicht bleibt. Die Frage ist dann warum der Ajax-Request so lange dauert.

20

@NextMike schrieb:

Die Variantendaten werden via Ajax geladen (wenn man es nicht abstellt). Das Caching macht wohl nur der Browser aber nur solange man in der Artikelansicht bleibt. Die Frage ist dann warum der Ajax-Request so lange dauert.

VS  „Bei mir werden die Varianten gecached“ 

widerpspricht sich doch dann - oder nicht? Ein „normaler“/nicht-Varianten Artikel ist ja technisch gesehen in Shopware eine Variante mit nur einer Hauptvariante. Eine Variante ist in Shopware technisch gesehen eine Hauptvariante mit mehreren Untervarianten. Und diese Untervarianten werden ja anscheinend nicht gecached - sonst würde ja schon der erste Aufruf die gleiche Geschwindigkeit wie die nachfolgenden besitzen. In Normal-Sprech werden damit Varianten nicht gecached - in Tech-Sprech wird anscheinend nur die Hauptvariante gecached (oder - aber weniger wahrscheinlich - die Variantenwechselfunktion hat ein Problem oder - noch unwahrscheinlicher - das Problem liegt ganz wo anders). 

Somit werden eben keine Varianten gecached sondern nur normale Artikel und die Hauptvariante korrekt. Die Vermutung liegt dann ziemlich nahe, dass sich man den Cache-Warmup mal genau ansehen sollte - und somit ist die Aussage von @motorg „Ich glaube eher es ist ein Problem von Shopware“ wohl sehr, sehr, sehr wahrscheinlich.