Guten Morgen, wir sind zur Zeit am Testen und versuchen einen alten 3.5 Shop auf 4 zu bekommen. U.a. geht es um mehrere tausende Artikel. Nun braucht z.B. der alte Shop über die normale API ca. 130 Sekunden für 1000 Artikel ohne Bild. Hingegen brauche ich mit der REST API 52 Sekunden für nur 100 Artikel. Dabei spielt es keine Rolle ob mit oder ohne Bild. Die Geschwindigkeit bleibt gleich. Für uns ist das miserabel. Wie lange brauchen eure Imports? Wie kann ich das Ganze beschleunigen. So ist es einfach zu langsam.
Direkter Vergleich: Neue API = 200 Artikel => 60 Sekunden reiner Artikelimport ohne überprüfung ob dieser bereits besteht. Alte API = 200 Artikel => 18 Sekunden mit vorheriger Überprüfung ob der Artikel bereits besteht. Wie sind eure Erfahrungen. Würde mich echt interessieren. An Shopware :shopware: Wird da in den kommenden Updates evtl nachgebessert?
Hi! Ja bei mir verhält es sich nicht anders: post44313.html#p44313 Ich importiere über eine XML-Datei. CSV konnte ich noch nicht testen. Manueller Import über das Backend ist für mich keine Lösung.
ja leider ist es ewig lahm Und es wird schlimmer je mehr Artikel drin sind. Und noch Varianten und noch mit Bild und man hat seine helle Freude Da hilft bald echt nur eine Wawi damit man weiss was geklappt hat und was nicht.
Folgende Fehlermeldung bekomme ich etwa solange ich das memory_limit nicht erhöhe. PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in shopware-4/engine/Library/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php on line 107
Die CPU-Auslastung vom Webserver liegt beim Import permanent zwischen 94 und 100% PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20 0 644m 441m 4268 R 97 11.2 27:36.01 apache2
Der MySQL Server tut dabei aber gar nichts.
wenn du jetzt noch htop machst siehste das er irgendwas im phpcode rumwurschtelt
Da ich nicht denke, dass es eine baldige Lösung für dieses Problem gibt, werde ich versuchen die Daten direkt in die Datenbank zu importieren und dort auch zu aktualisieren. Ich melde mich bei Gelingen
Da hätte ich evtl. auch interesse. Wahrscheinlich ist das aber nicht Ohne. 60t Artikel und mehr… mehrere Subshops mehrere Kundengruppen mehrere Sprachen Variantenartikel Das könnte alles zusammen kritisch werden, mit einem direkten Import in die DB.
So also ich habe nun die ersten Ergebnisse: Ein Import/Update von 7000 Artikel (mit einem Preis, Zusatzfeldern und Filtereigenschaften) benötigt bei mir nun “nur” 22 Minuten. Dabei verwende ich aber die Datenbankanbindung über Shopware, also Shopware()->Db(). Dies stellt auch sicher, dass man keinen Quirks mit den Keys in den Tabellen bekommt, was gerade bei den Filter-Eigenschaften geholfen hat. Wie ich über diese Variante Bilder in die Datenbank bekomme ist mir noch unklar. Ich werde jedoch einen anderen Weg gehen und die Bilder in 4 Größen auf einem Imageserver ablegen und im Template direkt referenzieren á http://server/bilder/klein/artikelnummer.jpg Nun werde ich noch Übersetzungen importieren. Dabei habe ich jedoch etwas Angst bekommen, da die s_articles_translations nicht alle 20 attr Felder aufweist. Wurden da Felder schlicht nicht angelegt? LG, Markus
Bei 60t Artikeln ist mM nach wirklich keine Doctrine gestützte Lösung mehr eine gute Wahl. Da solltest du dann tatsächlich raw sql wählen und die Statements schön auf Queues aufteilen. Ich würde allgemein Importprozesse immer als Terminalanwendungen laufen lassen und der Imageprozess sollte immer losgekoppelt und asynchron laufen.
geht bei euch jedes mal die sitemap.xml zu erstellen? und was ich auch nicht verstehe, warum muss er immer jedes Feld durchrappeln ohne Rücksicht auf Verlust. Es wäre schön wenn man sagen könnte welche Variantenfelder überhaupt befüllt sind, das würde schon ne Menge Power sparen.
Also nach Rest Standart ist es schon sinnvoll und so gedacht auch bei jedem PUT Request den kompletten Datensatz mitzuliefern. Was würdest du denn sonst machen, wenn du zB bei einigen Artikeln nur einen Parameter rauslöschen willst, dann müsste es ja noch eine Methode geben RESTful arbeitet halt sehr Strikt nach HTTP Standart.