Hallo, wir haben einen Shop mit > 50.000 Artikeln und > 1.000 Kategorien. Auf Shopware 3.5.6 läuft alles wunderbar. Auf Shopware 4 (-> 4.0.4) haben wir große Performance-Probleme. Insbesondere scheint dies an u.g. SQL zu liegen. Zum einen läuft sie sehr lange und zum zweiten wird sie mehrfach ausgeführt (>100 mal gleichzeitig). Der Shop lässt sich nicht aufrufen. Teilweise bringt es das System komplett zum absturz. Der 4.0 Shop läuft auf dem gleichen Server wie der 3.5.6 -> an der Performance des Servers kann es darum eigentlich nicht liegen. Hat jemend eine Idee? Vielen Dank! SELECT ( s0\_.`right` - s0\_.`left` -1 ) /2 AS sclr0, ( SELECT COUNT( s1\_.id ) AS dctrn\_\_1 FROM s\_categories s2\_ INNER JOIN s\_articles\_categories s3\_ ON s2\_.id = s3\_.categoryID INNER JOIN s\_articles s1\_ ON s1\_.id = s3\_.articleID AND ( s1\_.active =1 ) WHERE s2\_.active =1 AND ( s2\_.`right` \<= s0\_.`right` AND s2\_.`left` \>= s0\_.`left` ) ) AS sclr1, s0\_.id AS id2, s0\_.parent AS parent3, s0\_.description AS description4, s0\_.position AS position5, s0\_.`left` AS left6, s0\_.level AS level7, s0\_.`right` AS right8, s0\_.metakeywords AS metakeywords9, s0\_.metadescription AS metadescription10, s0\_.cmsheadline AS cmsheadline11, s0\_.cmstext AS cmstext12, s0\_.active AS active13, s0\_.template AS template14, s0\_.blog AS blog15, s0\_.showfiltergroups AS showfiltergroups16, s0\_.external AS external17, s0\_.hidefilter AS hidefilter18, s0\_.hidetop AS hidetop19, s0\_.noviewselect AS noviewselect20, s0\_.changed AS changed21, s0\_.added AS added22, s4\_.id AS id23, s4\_.categoryID AS categoryID24, s4\_.attribute1 AS attribute125, s4\_.attribute2 AS attribute226, s4\_.attribute3 AS attribute327, s4\_.attribute4 AS attribute428, s4\_.attribute5 AS attribute529, s4\_.attribute6 AS attribute630 FROM s\_categories s0\_ LEFT JOIN s\_categories\_attributes s4\_ ON s0\_.id = s4\_.categoryID WHERE s0\_.active =1 AND s0\_.`left` \>2 AND s0\_.`right` \<12197 HAVING sclr1 \>0 OR s0\_.external IS NOT NULL ORDER BY s0\_.`left` ASC
Hi, das ist wahrscheinlich die Generierung der SEO-Links. Diese werden wir in der nächsten Minor-Version verbessern. Dann sollte das Verhalten nicht mehr auftreten. 
Viele Grüße, Marcel
[quote=„Marcel S“]Hi, das ist wahrscheinlich die Generierung der SEO-Links. Diese werden wir in der nächsten Minor-Version verbessern. Dann sollte das Verhalten nicht mehr auftreten. Viele Grüße, Marcel[/quote] Wie wird diese Änderung aussehen? Die aktuelle Implementierung, die URLs bei Besuch eines Kunden zu erzeugen, ist die falsche Vorgehensweise. Es sollte zumindest möglich sein, die URL-Erzeugung über ein cron-Skript zu steuern. Grüße Klaus-Peter
[quote=“kapeha”] Die aktuelle Implementierung, die URLs bei Besuch eines Kunden zu erzeugen, ist die falsche Vorgehensweise. [/quote] Vollste Zustimmung. Die Generierung könnte durch einen Cronjob passieren, oder aber auch direkt über eine modifizierte Backendfunktionalität (z.B. Cache löschen + Rebuild), jedenfalls sollte sie nur einmal angestoßen werden können und den Seitenbesuch keinesfalls beeinträchtigen. Die URL Generierung an ein Frontend"event" (ich nenne den Besuch eines Kunden jetzt einfach mal so) zu koppeln, macht keinen Sinn, wenn sie nicht asynchron und auch nur ein einziges mal ausgeführt werden kann. Bei sehr sehr gut besuchten Shops mit einer hohen Anzahl an Kategorien und Produkten führt es teilweise zu Locks (Cache stampede/dog piling) und in Folge dessen zur Nichterreichbarkeit der Seiten. Das betrifft leider nicht nur die URL Generierung, aber dort ist es mir besonders aufgefallen, da die Erzeugung insgesamt sehr ineffizient gelöst war (ich kann allerdings leider nur von v3.5 berichten, der grundsätzliche Mechanismus scheint sich nach diesem Bericht allerdings nicht geändert zu haben).
Ist dieses Problem behoben?
[quote=“technikexpert”]Ist dieses Problem behoben?[/quote] Ja, in der aktuellen Version (>= 4.1) ist das in den Cache-Einstellungen konfigurierbar. Man kann die Erzeugung der SEO-URLs auf die Einstellung “cronjob” umstellen.