Hallo,
wir haben folgendes Problem:
Unsere Execution time des Servers in den Artikellisten ist recht ok, liegt bei ca 1-3 Sekunden. Geht noch besser.
Sobald wir aber im Admin einen Artikel einer neuen Kategorie hinzufügen, einen neuen Artikel einfügen oder die Attriubte eines Artikels ändern, geht die Executiontime der Kategorie, die bearbeitet wurde, auf über eine Minute hoch und mehr.
Wir haben unsere Seite vor kurzem gerelauncht mit der Version 4.5.9.
Vorher lief der Shop auf der veralteten Version 4.2.0. Da ist dieses Phänomen nicht aufgetreten. Seit Version 4.5.0 werden ja Views zum Cachen der Datenbank-Abfragen benutzt. Wir vermuten, dass da das Problem liegt. Sobald sich die Anzahl der Artikel in den Kategorien ändert bzw. es Änderungen beispielsweise in der oxobject2attribute gibt, stimmt auch ja der Result mit den Views nicht mehr überein. So erstellt er diese nach jeder Änderung immer wieder neu. Und dies dauert bei uns manchmal mehrere Minuten, je nachdem wie groß die Kategorie ist.
Tritt bei euch dieses Phänomen ebenfalls auf oder habt ihr Ideen, wie wir dieses Problem lösen können?
In der Praxis bedeutet das, dass wir tagsüber keine Artikel pflegen können.
Hier noch ein paar Infos:
- 6 Virtuelle Prozessorkerne, AuthenticAMD, Quad-Core AMD Opteron™ Processor 2352
- 16GB Arbeitsspeicher
- 200 GB Festplattenplatz
- OXID CE4.5.9_43186
- ca 1500 Artikel verteilt auf ca 15 Kategorien, mit je ca. 4-6 Attributen
An der Hardware kann es also nich liegen…
gleiches Verhalten, wenn nach erfolgten Änderungen zuerst mal unter Service -> Tools -> VIEWS aktualisieren ausgeführt wird?
Grad getestet. Das gleiche Verhalten kommt auch nach den Views updaten im Admin.
Auch wenn keine Änderungen im Admin vorgenommen wurden, die Views aber trotzdem übers Admin aktualisiert wurden, ist die Execution time ähnlich.
[QUOTE=Egoist;90668]Grad getestet. Das gleiche Verhalten kommt auch nach den Views updaten im Admin.
Auch wenn keine Änderungen im Admin vorgenommen wurden, die Views aber trotzdem übers Admin aktualisiert wurden, ist die Execution time ähnlich.[/QUOTE]
Ich weiß, ganz blöde Frage, aber löschen Sie den Cache nach der Änderung oder loggen sich aus dem Backend aus?
Das sich Views neu erstellen kommt mir unbekannt vor. Der View ist ja im Endeffekt nur eine Zwischenschicht die Datensätze vorgruppiert. Solange an der Struktur nichts geändert wurde, ist den Datenbankviews eigentlich egal, was in der Tabelle steht.
Was beim Ändern der Kategorie z.B. noch passiert ist, dass die Anzahl der Artikel für die Pagination etc neu berechnet und im Datensystem (oxUtilsCount, nicht oxCache) gecacht wird. Dieses Caching gab es zu 4.2.0 imho noch nicht. Vielleicht braucht dieses Caching zu lange.
Das mit den Views ist nur eine Vermutung. Ursache ist auf jeden Fall das Ändern der Kategorie oder Attributen. Das löst eine einmalige Verzögerung von mehreren Minuten aus, wenn man danach die Kategorie neu aufruft.
Ist das Array der Cache-Datei mit “aLocalCatCache” im Namen nach dem entsprechenden Ändern für die entsprechende Kategorie leer?
Was passiert denn wenn Sie in dieser Cache-Datei für die grad geänderte Kategorie eine Zahl eintragen?
Dieses “Problem” kann imho mehrere Ursachen haben, ich würde vermuten es liegt wirklich daran, dass mit Änderung ein gecachter Zustand resettet wurde und das braucht einfach einen Moment länger bis es wieder voll ist, was für mich aber vollkommen normal ist.
Die Ladezeiten sind ohnehin sehr unterschiedlich und teilweise nicht akzeptable.
TEST
sec / page- mit Google Chrom (Klickreihenfolge heute ab ca. 21:30):
6,52 Hompage
6,29 Neu im Shop
2,01 Sale
1,45 Marken
1,39 Egoist
1,14 Kontakt ( Ansicht nicht ok - will unsicher Inhalte laden)
1,2 -1,4 zu Links in Fusszeile
2.14 Produkseite http://www.egoist.de/jeans/3/
289 kb => 1 Bild oben
480 kb => 20x2 Bilder x 12kb
bis zu fast 1 MB.
Das Thema Performance und Chache wurde hier schon diskutiert:
http://forum.oxid-esales.com/showthread.php?p=86945#post86945
Und Views hier (soll die Performance verbessern(!) ob man es glaubt oder nicht):
http://forum.oxid-esales.com/showthread.php?t=14473
Vielleicht lässt sich daraus was ableiten ?
PS: Bei welchem Provider läuft der Shop und Shared Hosting oder Root Server wäre noch interessant.
Danke Earlybird, daran arbeiten wir gerade. Der Seitenaufbau wird merklich schneller.
Aber die Hauptursache liegt immer noch darin, das die Seite vom Server zu langsam ausgeliefert wird.
Vor allem wenn es große Kategorien sind und erst recht wenn man das erste Mal darauf klickt - 5-30 Sekunden ;-(
Die Kategorien-Anzahl ist aber rel. gering:
ca 1500 Artikel verteilt auf ca 15 Kategorien, mit je ca. 4-6 Attributen
Steht in der DB bei oxcategories wirklich nur 15 ?
Grundsätzlich kann ich bestätigen, dass bei grossen Kategoriebäumen (z.B. grösser 1000), ein Klick auf eine Kategorie ca. 80% der Gesamtladezeit für eine neue Seite ausmacht.
Mach doch auch mal einen Vergleichstest mit und ohne Bilder (das pictures Verzeichnis abhängen), um zu sehen welchen Einfluss das hat.