xt Commerce 4.2 Performance

[sijandi]

Hallo miteinander,

nach dem Update auf die Version 4.2 inkl. Patch ist die Performance meines Shops enorm zusammengebrochen, so dass ich Ihn als nicht mehr bedienbar bezeichnen würde. Ladezeiten wenn alle Plugins aktiviert >20 Sek!

Hat jemand ähnliche Erfahrungen? Weiss jemand was ich machen könnte?

Vielen Dank und beste Grüsse an alle

Sijandi

www.drachenhort.ch

[alexsm]

Hmm.. gab mal so etwas ähnliches.. lag damals am Master-Slave Plugin /"Master + Ajax" und dann war irgendein "Auswahl/Optionsfeld" auf true(was nicht nötig ist). Das hat dann den ganzen Shop bzw. insbesondere die Artikelauswahl extrem verlangsamt in Richtung nicht zumutbar.

Müsstest mal ggf. testen ;-)

[sijandi]

Hallo Alexsm,

vielen Dank für den Tip, hat leider nichts gebracht. Egal was ich im Master/Slave Plugin einstelle, entweder schnellt die PArsetime ins unendliche, oder es geht gar nichts mehr, oder es führt auf eine weisse Seite. Ich bin am Ende mit meinem Latain :-(

Gruss

Sijandi

[schenphi]

Hallo sijandi

Habe genau das gleich Problem, bei mir ist es jedoch nir beim checkout. Dieser ist extrem langsam und wenn viele Produkte im Warenkorb sind, führt es sogar zu einem "Fatal error", da die execution time von 30 sekunden überschritten wird.

Shopversion: 4.2.00

Hat jemand das gleich Problem oder eine Lösung?

 

Grüsse

schenphi

 

[Amrit]

....

Shopversion: 4.2.00

Hat jemand das gleich Problem oder eine Lösung?

 

Grüsse

schenphi

 

​wir hatten so etwas schon bei Version 4.1.10, wir hatten den Shop auf einem "Shared Server"

der Shop war sehr langsam und ab 6-8 Artikel im Warenkorb gab es eine weiße Seite beim Checkout.

Jetzt haben wir einen "Managed Server" mit optimaler konfiguration, ist zwar etwas teurer als "Shared.."

aber dafür läuft der Shop optimal.

 

[mbwwad]

Wir haben nun das selbe Problem.

Mit Version 4.1.10 lief noch alles einwandfrei.
Nach dem Update auf Version 4.2 haben wir nun Ladezeiten von über 20 Sekunden, auf allen Seiten, egal ob Produkte enthalten sind oder nicht.

Das Master-Slave-Plugin wird nicht verwendet.
Auch habe ich mal alle Plugins deaktiviert, um zu sehen ob es an einem Plugin liegt, hat aber auch nichts geändert.

Ist wirklich die einzige Lösung, sich einen Managed Server zuzulegen?
Hilft das auch garantiert?

-------

Also es scheint wohl mit den Kategorien zusammenzuhängen.
Auf Seiten, wo keine Kategorien angezeigt werden (z.B. Warenkorb oder Benutzerregistrierung), ist alles rasend schnell.
Sobald aber auch nur die Hauptkategorie angezeigt werden muss, sind die Ladezeiten wieder extrem langsam.

Hat hier jemand einen Tipp?
z.B. bestimmte zusätzliche Indizies in der Datenbank?

[oldbear]

hmmm,

hatte jetzt schon hin und wieder das Problem ( ich teste remote mit MAMP auf dem Mac, hatte das aber auch in Live-Shops ),

dass für bestimmte Tabellen die Keys "disabled" waren ( sieht man im phpMyAdmin, wenn man die Indices ansieht ). Ich habe allerdings keinerlei Ahnung, wie das zustande kommt ( evt. beim Einspielen von Backups ????? ) !

mal kontrollieren !

Im Falle dass, im phpMyAdmin z.B. eingeben:

ALTER TABLE xt_categories ENABLE KEYS

gesucht nach GottWeissWas ...

Ich definiere aber immer noch zusätzliche Indizes für categories_left und categories_right

Grüsse

[mbwwad]

Danke für die Tipps!

Ich habe sowohl den SQL-Befehl ausgeführt, als auch die beiden Indizies angelegt, hat aber leider nicht geholfen.

Ich nehme an, es liegt an ungünstigen SQL-Abfragen, da wir auch sehr viele Kategorien haben.
Es gibt aber nur eine Hauptkategorie, der alle anderen untergeordnet sind und auch wenn nur diese angezeigt wird, laden die Seiten so lange.

Nur wie finde ich die problematischen SQL-Abfragen heraus, damit ich ggf. Handlungsmöglichkeiten ableiten kann?

[mbwwad]

Inzwischen konnte ich, auch mit Hilfe des Hosters, schon mal folgende SQL-Abfrage als Übeltäter ausmachen:

-----------------------

SELECT
    COUNT(parent.categories_id) AS level,
    c.*,
    cd.*,
    su.*,
    cl.link_url,
    group_permission.*,
    shop.*
FROM xt_categories AS c
    CROSS JOIN xt_categories AS parent
    LEFT JOIN xt_categories_description cd ON c.categories_id = cd.categories_id  and cd.categories_store_id='1'
    LEFT JOIN xt_seo_url su ON (c.categories_id = su.link_id and su.link_type='2'  and su.store_id='1')
    LEFT JOIN xt_categories_custom_link_url cl ON (cl.categories_id = c.categories_id  and cl.store_id='1')  
    LEFT JOIN xt_categories_permission group_permission ON (group_permission.pid = c.categories_id and group_permission.pgroup = 'group_permission_1' )
    LEFT JOIN xt_categories_permission shop ON (shop.pid = c.categories_id and shop.pgroup = 'shop_1' )  
WHERE
    c.categories_status = '1' and
    c.categories_left BETWEEN parent.categories_left AND parent.categories_right and
    cd.language_code = 'de'  and
    cd.categories_store_id='1' and (
        (c.category_custom_link=0 and su.language_code = 'de'  and su.store_id='1') ||
        (c.category_custom_link=1 and cl.language_code = 'de'  and cl.store_id='1')
    ) and
    group_permission.permission IS NULL  and
    shop.permission IS NULL
GROUP BY
    c.categories_id,
    c.categories_left,
    c.categories_right
ORDER BY
    c.sort_order,
    c.categories_left,
    cd.categories_name;

-----------------------
benötigt meist mindestens 20 Sekunden zur Ausführung
-----------------------

Insbesondere das CROSS JOIN benötigt wohl viel Rechenzeit.

Da ich kein MySQL-Experte bin und die Abfrage selbst nicht ändern kann:

Kann ich die SQL-Abfrage durch besondere Indizies oder anderweitig beschleunigen?

Oder ist das Fazit: "kompensier die komplexe Abfrage mit besserer Hardware" ?

[oldbear]

mal ne Frage,

was für ein Template nutzt Du ? Die Query habe ich so noch nicht gesehen ... ist da ein Menamenu drin, das evt. immer den kompletten Kategoriebaum zieht ?

[mbwwad]

Das Template basiert auf dem xt_grid Template und enthält kein Megamenu.
Ich habe testweise auch schon das originale xt_grid geladen, hier ist die Performance aber genauso schlecht.

----

Die EXPLAIN-Auswertung hat mich auch noch nicht weitergebracht.

Besteht die Chance, dass irgendein kostenpflichtiger Support (xt:Commerce, MySQL-Experte o.a.) das Problem lösen kann?

[mbwwad]

Also die einzige Lösung für uns war nun das deutliche Reduzieren der Kategorien.
Jetzt läuft der Shop wieder so schnell wie vor dem Update.

Eine Möglichkeit wäre evtl. noch der MySQL Query Cache gewesen, aber den wollte unser Hoster auf dem Shared System nicht aktivieren. Ist auch nachvollziehbar.
Hier hatte jemand die selben Performance-Probleme mit der o.g. SQL-Abfrage und konnte es mit dem Query Cache bzw. einem MySQL Proxy lösen:
http://dba.stackexchange.com/questions/138755/cache-query-that-is-not-stored-in-querycache

[halousi]

Das kann ich bestätigen! Wir haben ~ 1.600 Kategorien und genau diese Abfrage erzeugt bei uns eine Ladezeit von ca. 10 Sekunden. Mit der Version 4.1 war das kein Problem. Gibt es dafür wirklich keine Lösung? So ist für uns die 4.2 leider unbrauchbar.

SELECT COUNT(parent.categories_id) AS level ,c.*,cd.*,su.*,cl.link_url,group_permission.*,shop.* FROM xt_categories AS c CROSS JOIN xt_categories AS parent LEFT JOIN xt_categories_description cd ON c.categories_id = cd.categories_id and cd.categories_store_id='1' LEFT JOIN xt_seo_url su ON (c.categories_id = su.link_id and su.link_type='2' and su.store_id='1') LEFT JOIN xt_categories_custom_link_url cl ON (cl.categories_id = c.categories_id and cl.store_id='1') left JOIN xt_categories_permission group_permission ON (group_permission.pid = c.categories_id and group_permission.pgroup = 'group_permission_1' ) left JOIN xt_categories_permission shop ON (shop.pid = c.categories_id and shop.pgroup = 'shop_1' ) WHERE c.categories_status = '1' and c.categories_left BETWEEN parent.categories_left AND parent.categories_right and cd.language_code = 'de' and cd.categories_store_id='1' and ((c.category_custom_link=0 and su.language_code = 'de' and su.store_id='1') || (c.category_custom_link=1 and cl.language_code = 'de' and cl.store_id='1') ) and group_permission.permission IS NULL and shop.permission IS NULL GROUP BY c.categories_id, c.categories_left, c.categories_right ORDER BY c.sort_order,c.categories_left,cd.categories_name

[df:bug]

Update auf xt:Commerce 5.

[halousi]

... wenn es so einfach wäre.

Das wollte ich eigentlich im Moment noch nicht. Wir haben zig Module und Templateanpassungen. Einige davon sind für 5 noch nicht verfügbar.

Aber das kann doch nicht so ein großes Problem sein, in der 4.1 hat das doch wunderbar funktioniert?

[Alex@4tfm]

1 hour ago, halousi said:

Das kann ich bestätigen! Wir haben ~ 1.600 Kategorien und genau diese Abfrage erzeugt bei uns eine Ladezeit von ca. 10 Sekunden. Mit der Version 4.1 war das kein Problem. Gibt es dafür wirklich keine Lösung? So ist für uns die 4.2 leider unbrauchbar.

 

Wenn Ihr 1600 Kategorien habt, dann würde ich eher das in Frage stellen. Ein Kunde von uns hat 130k Produkte und selbst er kommt mit 300 Kategorien aus...

[halousi]

äh, komischer Kommentar Alex@4tfm . Wir machen die Kategorien ja nicht zum Spaß an der Freude. Natürlich brauchen wir diese Anzahl an Kategorien auch. Oder habe ich irgendwo überlesen das 4.2 eine max. Kategorienbeschränkung hat? Die Frage ist, warum geht es mit 4.1 problemlos und mit 4.2 nicht und warum nimmt sich, obwohl das Problem bekannt ist keiner dieser Problematik an, sondern verweist uns auf eine weiteres, kostenpflichtiges Update. 4.2 haben wir auch bezahlt, können es aber nicht verwenden !!!

[oldbear]

hallo,

es schadet auf keinen Fall, categories_left und categories_right als zusätzliches Indizes anzulegen, das sollte schon was bringen ...

Grüsse