Artikel-Übersicht bricht nach 30 Sekunden Ladezeit ab bei 30 Mio Artikeln im Shop. Timeout Einstellu

Wir haben in unserem Shop über 100.000 Artikel mit jeweils 273 Varianten, also rund 30 Mio Einzelartikel. Eine Menge Artikel.

Nun ist es so, dass beim Aufruf exakt nach 30 Sekunden bei der Artikel-Übersicht im Backend der Aufruf mit „0 - communication fehler“ abbricht.

Die MySQL Abfrage zeigt, dass hier folgende Abfrage durchgeführt wird während der Zeit:

SELECT COUNT(*) AS dctrn_count FROM (SELECT DISTINCT id_0 FROM (SELECT s0_.id AS id_0 FROM s_articles_details s0_ INNER JOIN s_articles_attributes s1_ ON s0_.id = s1_.articledetailsID LEFT JOIN s_articles s2_ ON s0_.articleID = s2_.id LEFT JOIN s_articles_categories_ro s4_ ON s2_.id = s4_.articleID LEFT JOIN s_categories s3_ ON s3_.id = s4_.categoryID WHERE s0_.kind = 1 AND (s3_.path LIKE ‚%|3|%‘ OR s3_.id LIKE ‚3‘) ORDER BY s0_.id DESC) dctrn_result) dctrn_table

Er macht einen 30 Mio Datensätze select, welches natürlich mehr als 30 Sekunden mit MysQL dauert.

Jetzt die Frage, wo stelle ich das Timeout von 30 Sekunden in Shopware um?-

Wir haben bereits im Plesk die Scriptlaufzeit erhöht und die MysQL Config auf dem Server auch das timeout erhöht, aber nichts hilft hier die 30 Sekunden zu erhöhen.

Weiß jemand rat?

Hi,

ich würde eher darauf tippen, dass der Server noch einen Neustart braucht? Ich wüsste nicht, dass wir da explizit auf 30 Sekunden begrenzen, warum auch. 

Vom Prinzip her ist das von der Datenmenge für das Backend schon heftig, einfach weil SQL fürs Filtern / Suchen etc. tatsächlich die 3 Millionen Artikel durchlaufen muss. Im Frontend mit ES sollte das alles kein Problem sein, im Backend fehlen mir dazu etwas die Erfahrungswerte - hängt sicher auch davon ab, ob man die Varianten mit selektiert oder ob die Filter / Suchen nur über die “Stammartikel” laufen müssen. 

Besten Gruß,

Daniel 

[@Daniel Nögel](http://forum.shopware.com/profile/4010/Daniel Nögel “Daniel Nögel”)‍ , danke für die Hinweise. Server Neustart habe ich schon gemacht, bringt auch nichts.

Klar, 30 Mio Einzelartikel mit 100.000 Elternartikel ist sehr viel, wir haben dafür auch Elastic Search am laufen für den Shop, damit es im Frontend flott läuft, was im da auch hervorragend mit Elastic Search Funktioniert. Doch im Backend mal eben 30 Mio Datensätze per SELECT in MySQL durchführen braucht seine Zeit. Trotz 6 fach Prozessor und SSD Platten. Die Varianten sind hier nicht mit Angezeigt. Kurios sind wirklich die 30 Sekunden, die kann ich mit der Stoppuhr setzen, jedes mal.

Irgendwo ist hier ein Timeout auf 30 Sekunden gestellt. Die max_execution_time in PHP steht bei uns schon auf 3600 Sekunden, bringt aber auch nix.

Ihr kommt ja bald an amazon ran: http://marketplace-analytics.de/blog-amazon-sortimentgroesse-laender-vergleich

Was habt ihr für eine MySQL Version? Neben der Community-Edition gibts ja auch eine kommerzielle Edition, die nochmal schneller sein soll:

https://www.mysql.de/downloads/

Oder mal MySQLtuner ausprobieren: MySQL Performance Tuning – Thomas-Krenn-Wiki

Oder auf MariaDB gehen (Link1, Link2), wird leider nicht offiziell von Shopware unterstützt, läuft aber. Natürlich vorher alles doppelt und dreifach sichern.

PHP7 (mit Shopware 5.2!) bringt auch nochmal Performance, vielleicht ist da auch noch was möglich.

@raymond‍ , danke, aber an amazon kommen wir nicht ran. Grund sind die vielen Varianten. Derzeit sind 100.000 Produkte im Shop, mit jeweils 273 Varianten, ähnlich wie bei T-Shirts Größe, Farbe usw…

Die kommerzielle Edition unterscheidet sich nicht in der CE Version, außer bei Plugins, ansonsten alles gleich.

Wir nutzen MariaDB bereits schon, Grund sind hier lediglich die SELECT Abfrage in der Tabelle s_articles_details  die bei uns knapp 30 Mio Datensätze beinhalt und knapp 5 Gigabyte groß ist, dass muss erstmal alles durchlaufen werden. Daher haben wir auch ElasticSearch eingesetzt für das Frontend, was hervorragend klappt, aber eben nur im Frontend, weils im Backend nicht unterstützt wird. Dazu haben wir auch ein Ticket eröffnet, aber es ist derzeit nicht geplant das umzusetzen.

Daher, was nützt ES im Frontend, wenn im Backend weiterhin auf MySQL aufgebaut ist. Da nützt auch kein PHP7, wenn die SELECT 30 Mio Datensätze runter rattern muss.

Hast du denn mal versucht, eine zeitintensive Query direkt auf der Datenbank auszuführen, also ausserhalb von Shopware? Kann ja durchaus sein, dass deine Timeouts nicht aktiv sind oder dass du hier in ein Speicherproblem rennst.

Dann unbedingt mal MySQLtuner laufen lassen, zeigt Optimierungspotential an.

Habe eben eine Query z.b: SELECT * FROM s_articles_details WHERE additionaltext = ‚Test‘ durchgeführt. Das klappt, er rattert die 30 Mio Datensätze in ca 47 Sekunden runter mit MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 47.8143 Sekunden.)

Also dort gibt es kein Timeout.

Das Timeout kommt in Shopware immer exakt nach 30 Sekunden wenn die Datensätze aufgebaut werden sollen.

Speicher? 64 Gig Ram hat der Server und aktuell sind noch genug frei.

Kurios sind hier halt genau die 30 Sekunden die es da immer abbricht, nicht mehr, nicht weniger.

Das es lange dauert, da kann auch MySQL Tuner nix ändern, 30 Mio Datensätze sind kein Pappenstiel und es werden täglich mehr.

 

Vielleicht ist da doch Shopware am Ende?! Die Artikel auf mehrere Domains/Shops mit separaten Datenbankserver zu verteilen ist nicht drin?

Shopware ist nicht am Ende, irgendwo sind 30 Sekunden eingestellt, die es zu erhöhen gilt. Aber wo?

Eine Aufteilung ist leider nicht möglich.

Vielleicht ist das Problem nicht die Datenbankverbindung sondern das Timeout für Ajax-Requests.
In /engine/Library/ExtJs/overrides/Ext.Timeout.js wird die „ajaxTimeout“ (Standard ist 30, zu finden in „s_core_config_elements“) mit 1000 multipliziert. Das sind wohl Millisekunden, also genau deine 30s…

1 Like

@senor_dingdong‍ , genau, perfekt, das war das Problem. Im Backend kann man es auch sehen in den Grundeinstellungen, war auf 30 Sekunden eingestellt.

Manchmal ist es so einfach. Danke.