heute mal auf Deutsch: Hat jemand von euch Erfahrungen mit großen (wirklich großen) Artikelbeständen und Oxid eSales 4?
Wir haben hier eine modifizierte Version von der Community Edition 4.3 am laufen und das Admin-Interface raucht ab, wenn man in den Kategorien-Editor geht.
Das ganze kann man sich etwas so vorstellen: Es gibt in unserem Shop 87.336 Artikel in insgesamt 4.998 Warengruppen.
Die Artikeldaten werden täglich über eine eigene Schnittstelle (Talend Integration Suite) in die Shop-Datenbank importiert.
Das User-Seitige Frontend läuft nach wie vor sehr zufriedenstellend, alle Requests < 700ms.
Auf der Admin-Seite geht aber der Kategorien-Editor nicht mehr. Alle anderen Bereiche, Artikel, Attribute (davon gibt es auch tausende) laufen OK, nicht toll aber OK. Der Kategorien-Editor (insb. category_main) verbraucht dann beim rendern den gesamten Speicher (Memory-Limit sind üppige 256MB !!) und PHP verabschieded sich schließlich.
Wir haben in den letzten Wochen schon viel Reverse-Engineering betrieben, um die Shop-Performanz auf einem akzeptablen Niveau zu halten (Dinge wie Anzahl der Artikel pro Warengruppe mit in die Datenbank schreiben, statt jedes mal select count(*) etc.), und wir werden auch hier mal wieder Hand anlegen müssen. Mich würde nur interessieren, ob andere von euch schon mal ähnliche Projekte hatten und wie es da um die Performance stand, insbesondere, ob es Probleme mit vielen Kategorien gab und wie Ihr mit dem Problem umgegangen seid.
Das Problem: Der Entity-Manager von OXID ist ein wahnsinns Memory-Hog. Das Problem tritt beim initialisieren von oxCategoryList auf, in der buildList()-Methode. Im Gegensatz zu buildTree() (Kunden-Frontend) lädt diese ja bekannterweise alle Warengruppen und baut diesen eher hässlichen, eingerückten Baum. Bei 5000 Warengruppen ist der eh nicht mehr bedienbar, wozu es aber auch nicht kommt, da die Objekte so fett sind, dass 5000 davon schon nicht mehr in 256MB passen - das ist krass, aber lässt sich wohl vorerst nicht ändern.
Also müssen zwei Lösungen her:
Im Kategorien-Editor muss ich ja weiterhin durch die Hierarchie der Warengruppen navigieren können
Alle Auswahlen von Kategorien müssen durch was performanteres ersetzt werden (z.B. bei der Auswahl der Parent-Warengruppe)
Für 1) habe ich bereits eine Lösung erarbeitet, die ich bei Zeiten mal präsentieren werde. Dafür habe ich category_list so abgeändert, dass aus der einfachen, dummen Liste ein Browser wird, mit den man in der Hierarchie ab- und aufsteigen kann, wie in einem Dateisystem. Dafür entfällt diese nutzlose Dropdown im Header der Tabelle, wird auch nicht mehr gebraucht.
Für 2) hab ich noch nix, brauche ich aber auch nicht, da unsere Warengruppenhierarchie eh von extern kommt und nicht im Shop bearbeteitet werden darf. Ich habe buildList() dort einfach stillgelegt. Interessant wäre, den yui-Ajax-Popup zu verwenden. Das einzige Stück Code, das nicht von OXID sondern Yahoo kommt und das hat mit den 5000 kein Problem Liegt daran, fairerweise erwähnt, dass yui einen automatischen Nachlader hat, wie man es von Oracle-Produkten kennt. Man bekommt also nie alles zu sehen und so werden auch nur ein par zig Warengruppen auf einmal geladen. Für die Auswahl der Parent-Warengruppe wäre das Teil Ideal.
[QUOTE=PCO;29521]Für 1) habe ich bereits eine Lösung erarbeitet, die ich bei Zeiten mal präsentieren werde. Dafür habe ich category_list so abgeändert, dass aus der einfachen, dummen Liste ein Browser wird, mit den man in der Hierarchie ab- und aufsteigen kann, wie in einem Dateisystem. Dafür entfällt diese nutzlose Dropdown im Header der Tabelle, wird auch nicht mehr gebraucht.[/QUOTE]
So richtig Zeit (und Speicher) sparen für die Kategorien Navi kann man, wenn man sich ganz von den Objekten löst, und die Navi direkt aus der Datenbank erstellt…
Das Kat-Objekt kann man ja, wenn überhaupt notwendig, nach der Auswahl erstellen.
Und da kann man sogar ganz leicht wieder eine hierarchische Kat-Struktur anzeigen, was ja auch schmerzlich vermisst wird…
In dem Thread habe ich das mal im Front-End untersucht (und implementiert)…