Moin,
wir haben festgestellt, daß OXID trotz schnellem Server (Core I7 Quad-Core 3GHz, 12GB RAM, SSD) nur mittelprächtige Performance liefert. Dies bedeutet, daß fast alle Frontend-Seiten mindestens 300ms zum rendern benötigen. Unsere Analyse zeigt, daß die Ursache im Quellcode zu finden ist.
Wir haben mittels XDebug sowie KCacheGrind die Laufzeiten der Startseite analyisert. Die Render-Zeit für die Startseite benötigt ohne Xdebug ca. 400ms, mit Xdebug 1.6 Sekunden. Wir haben die prozentuale Verteilung der Aufrufe analysiert.
Die Top-CPU-Zeit-Verbrater finden sich wie folgt:
Das Hauptproblem ist allerdings, daß scheinbar keine Objekte in OXID gecached werden und unnötige Magie verwendet wird. Wird ein und dieselbe Kategorie mehrfach aus der Datenbank geladen, so wird diese auch mehrfach im Speicher vorgehalten. Dort findet man recht schnell heraus, daß auch mehrmals oxBase->_setFieldData aufgerufen wird, was in unserer Analyse 20% der gesamten Laufzeit der Startseite betrug.
Ein weiterer Aspekt ist die Vorhaltung sämtlicher Werte als Objekt, wodurch unnötig viel Speicher verschwendet wird. Über die Gründe, warum die OXID-Entwickler dies so tun, kann nur spekuliert werden. Dies hat aber zur Folge, daß OXID ohne enorme Eingriffe nicht wesentlich beschleunigt werden kann.
Gibt es seitens der OXID-Entwickler Lösungsansätze, daß die Mechanismen, die zur "Langsamheit" beitragen, nicht mehr verwendet werden? Denkbar wäre z.b. die Umstellung auf Doctrine2, welches aktives Caching unterstützt. Hierdurch wäre auch keine Vorhaltung der einzelnen Datenbankfelder als Objekt mehr nötig.
Gruß
vschmi
wir haben festgestellt, daß OXID trotz schnellem Server (Core I7 Quad-Core 3GHz, 12GB RAM, SSD) nur mittelprächtige Performance liefert. Dies bedeutet, daß fast alle Frontend-Seiten mindestens 300ms zum rendern benötigen. Unsere Analyse zeigt, daß die Ursache im Quellcode zu finden ist.
Wir haben mittels XDebug sowie KCacheGrind die Laufzeiten der Startseite analyisert. Die Render-Zeit für die Startseite benötigt ohne Xdebug ca. 400ms, mit Xdebug 1.6 Sekunden. Wir haben die prozentuale Verteilung der Aufrufe analysiert.
Die Top-CPU-Zeit-Verbrater finden sich wie folgt:
- 24%: smarty_include
- 18%: smarty->fetch
- 17.27%: oxShopControl->_process
Das Hauptproblem ist allerdings, daß scheinbar keine Objekte in OXID gecached werden und unnötige Magie verwendet wird. Wird ein und dieselbe Kategorie mehrfach aus der Datenbank geladen, so wird diese auch mehrfach im Speicher vorgehalten. Dort findet man recht schnell heraus, daß auch mehrmals oxBase->_setFieldData aufgerufen wird, was in unserer Analyse 20% der gesamten Laufzeit der Startseite betrug.
Ein weiterer Aspekt ist die Vorhaltung sämtlicher Werte als Objekt, wodurch unnötig viel Speicher verschwendet wird. Über die Gründe, warum die OXID-Entwickler dies so tun, kann nur spekuliert werden. Dies hat aber zur Folge, daß OXID ohne enorme Eingriffe nicht wesentlich beschleunigt werden kann.
Gibt es seitens der OXID-Entwickler Lösungsansätze, daß die Mechanismen, die zur "Langsamheit" beitragen, nicht mehr verwendet werden? Denkbar wäre z.b. die Umstellung auf Doctrine2, welches aktives Caching unterstützt. Hierdurch wäre auch keine Vorhaltung der einzelnen Datenbankfelder als Objekt mehr nötig.
Gruß
vschmi