Neu Hilfe - Performanceproblem mit Shop durch Worker

[mvh]

Leider ist die Tabelle bereits leer bei uns.

Dann muss ich leider passen. Ich habe damals (fast) alle sqls im Zusammenhang mit Abgleich analysiert, bis ich fündig wurde.

 

[css-umsetzung]

Du solltest mal den SQL Server neu starten und diesen Befehl dann ausführen um zu sehen wie lange der dann braucht.
Wenn in der Tabelle ein Artikel vorkommt, dann ist der für eine bestimmte Kundengruppe gesperrt, in der Regel wird diese Tabelle immer leer sein, weil das ja kaum einer nutzt.

Also für mich gehört dieser Aufruf eher zu einem normalen Artikelaufruf von einem User.
Und klar wenn die Datenbank eh schon im stress ist und der Shop nicht im Wartungsmodus ist, dann könnte das schon etwas eng werden mit der Performance, insbesondere bei deiner ungewöhnlichen Menge an Artikel und Merkmale.

aber Teste den Befehl mal wirklich mit einem kalten MySQL Server.

 

[mvh]

Leider ist die Tabelle bereits leer bei uns.

Wir hatten noch vor langer Zeit das Problem, dass bei unserem Provider genau auf diesem Server noch andere große Shop-Kunden liefen, und wir haben uns einander gestört. Wir wurden auf einen anderen Server portiert.

 

[xadoX]

Wir hatten noch vor langer Zeit das Problem, dass bei unserem Provider genau auf diesem Server noch andere große Shop-Kunden liefen, und wir haben uns einander gestört. Wir wurden auf einen anderen Server portiert.

Unser Shop läuft exklusiv auf dem Server.

 

[xadoX]

Wir haben die Ursache gefunden. Und zwar ist es eine Einstellung im Flexmenu des Dropper.



Setzt man diese auf nein, dann verschwindet der SQL und auch die daraus resultierenden Performanceprobleme.

 

[css-umsetzung]

Aber der SQL Query passt irgendwie nicht zu der Kategorie anzeige des Mega Menüs.
Der Query fragt ja speziell einen Artikel ab der aufgerufen wird.

Die Einstellung die du da hast macht das System im laufendem Betrieb auch langsamer, das stimmt schon, wäre aber ein anderer Query der dafür benötigt wird.

 

[xadoX]

Das können die Jungs von Kreativkonzentrat sicherlich aufklären.
Meinem Verständnis nach prüft dieser SQL, ob eine Kategorie leer ist. Und anscheinend jedes Mal erneut, wenn der Abgleich läuft und Artikeldaten abgleicht.
Ich hab denen gerade davon berichtet. @Kreativkonzentrat

 

[OliverS]

Aber der SQL Query passt irgendwie nicht zu der Kategorie anzeige des Mega Menüs.
Der Query fragt ja speziell einen Artikel ab der aufgerufen wird.

Die Einstellung die du da hast macht das System im laufendem Betrieb auch langsamer, das stimmt schon, wäre aber ein anderer Query der dafür benötigt wird.

Tatsächlich fragt die Query relativ umständlich den ersten Artikel in der jeweiligen Kategorie ab, der für die Kundengruppe sichtbar ist. Ich hatte schon vermutet, dass es ggf. am Zusammenspiel vom Template und einem Plugin liegt. Dropper hatte ich da nicht wirklich auf dem Schirm, aber hätte ich haben sollen. Der Shop benutzt eine ähnliche Abfrage, die ich probehalber optimieren wollte (per NOT IN, statt LEFT JOIN). Aber da es dann doch keine Abfrage vom Shop war, konnte ich das nirgends einpflegen.

 

[Kreativkonzentrat]

Das können die Jungs von Kreativkonzentrat sicherlich aufklären.
Meinem Verständnis nach prüft dieser SQL, ob eine Kategorie leer ist. Und anscheinend jedes Mal erneut, wenn der Abgleich läuft und Artikeldaten abgleicht.
Ich hab denen gerade davon berichtet. @Kreativkonzentrat

Hallo, die Query kommt genau aus der Einstellung die ihr schon gefunden habt. Was mich wundert ist warum der Shop beim Abgleich überhaupt an den Punkt kommt das Frontend / Template zu rendern. Möglicherweise ist es aber auch nur ein Seiteneffekt der Auftritt weil ja beim Abgleich trotzdem Kunden auf dem Shop unterwegs sind. Und durch die vielen Queries zwingt es den Shop dann in die Knie.

Ich habe eine experimentelle Version vom Flex Menu welche versucht das Problem etwas zu mitigieren. Kannst du dich bei uns mal per Ticket melden und dann testen wir die Änderungen mal?

https://kreativkonzentrat.de/Kontakt

Danke & beste Grüße,

Martin