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.
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.
bei mir liegen die Zeiten idR bei 600 bis 800 ms (Firebug). Mein Server ist auch nicht ganz so schnell wie bei dir.
Welche Version setzt du ein CE oder EE? Das erweitere bzw. gute Caching ist ja der EE vorbehalten. Wahrscheinlich kommt man ohne an der Caching-Schraube zu drehen nicht in die Bereich, die man als schnell bezeichnen kann.
Bleib dran, wäre auch an einem schnelleren Shop intessiert.
@vschmi:
dein Beitrag ist eher etwas für die dev-Liste. Hier hört kein Oxid-Entwickler mit. Dort schon.
Marco kann dir sicher erklären wie man da reinkommt
Die Top-CPU-Zeit-Verbrater finden sich wie folgt:
24%: smarty_include
18%: smarty->fetch
17.27%: oxShopControl->_process
Ich denke die Punkte überschneiden sich und besagen einfach dass die Funktionsaufrufe aus dem Template heraus Zeit brauchen, was zu erwarten ist.
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.
Wobei man ganz klar sagen muss, dass Performance immer auch Projektgeschäft ist. Es gibt zwar so ein paar grundlegende Dinge aber letztlich muss man sich immer die Konstellation ansehen. Ich bin mir nicht sicher, ob das so aus der Ferne überhaupt sinnvoll ist.
[QUOTE=leofonic;136466]Ich denke die Punkte überschneiden sich und besagen einfach dass die Funktionsaufrufe aus dem Template heraus Zeit brauchen, was zu erwarten ist.
Aber wäre es auch tatsächlich schneller?[/QUOTE]
Ja. OXID erzeugt für jedes Datenbankfeld ein neues Objekt, und die ADODB cacht keine Ergebnisse. Beides wäre mit Doctrine2 nicht nötig. Das bringt natürlich erhebliche Umbauarbeiten im System mit sich, welches die OXID-Entwickler sehr wahrscheinlich nicht auf sich nehmen.
[QUOTE=Marco Steinhaeuser;136519]Wobei man ganz klar sagen muss, dass Performance immer auch Projektgeschäft ist.[/QUOTE]
Jein. Eine komplett frische Installation auf einem schnellen Server ist ebenso “langsam” (200ms). Das bekommt man nur schwer wegoptimiert.
[QUOTE=vschmi;136549]Ja. OXID erzeugt für jedes Datenbankfeld ein neues Objekt, und die ADODB cacht keine Ergebnisse. Beides wäre mit Doctrine2 nicht nötig.
[/QUOTE]
Das heißt aber noch nicht dass der Shop mit Doctrine schneller wäre. Wenn man 100 unterschiedliche Artikel lädt ist das mit Caching genauso schnell wie ohne, Doctrine selbst bringt dagegen einigen Overhead mit.
[QUOTE=leofonic;136575]Das heißt aber noch nicht dass der Shop mit Doctrine schneller wäre. Wenn man 100 unterschiedliche Artikel lädt ist das mit Caching genauso schnell wie ohne, Doctrine selbst bringt dagegen einigen Overhead mit.[/QUOTE]
Das ist nicht korrekt. Doctrine2 kann dank zahlreicher Strategien (z.b. APC, Memcached, XCache) Objekte über Seitenaufrufe hinweg cachen. Außerdem wird bei mehrfachem Abruf von Objekten bei ein- und demselben Request kein erneuter Datenbankzugriff nötig.
Du willst dir insbesondere den Link zur Doctrine2-Performance durchlesen. Unter dem Strich wird die Performance wesentlich höher sein, als es OXID derzeit mit einem Objekt pro Wert hinbekommt, vom wesentlichen geringeren Speicherbedarf einmal ganz abgesehen.
Natürlich erfordert das einen nahezu kompletten Umbau von OXID, was ohne die OXID eSales AG nicht machbar ist. Aber egal, wie es in Zukunft aussehen wird:
Ich bezweifle ja gar nicht dass Doctrine gute Performance hat. Ich glaube aber du unterschätzt die Performance der jetzigen Lösung. Z.B.: Felder als Objekte - das kostet sehr wenig Performance und die wenigen Dinge die dort passieren, z.B. Unterscheidung raw und formatiert, müssen ja irgendwo stattfinden. Aber du solltest das wirklich auf der Mailingliste vorschlagen, denn hier liest niemand der Devs mit.
[QUOTE=leofonic;136578]Ich bezweifle ja gar nicht dass Doctrine gute Performance hat. Ich glaube aber du unterschätzt die Performance der jetzigen Lösung. Z.B.: Felder als Objekte - das kostet sehr wenig Performance und die wenigen Dinge die dort passieren, z.B. Unterscheidung raw und formatiert, müssen ja irgendwo stattfinden. Aber du solltest das wirklich auf der Mailingliste vorschlagen, denn hier liest niemand der Devs mit.[/QUOTE]
Da sprechen meine Messungen leider eine andere, sehr deutliche Sprache. Bei einer Messung von gerade eben gehen 20% für oxBase->_setFieldData drauf. Kein Wunder, denn bei der getesteten Startseite wird es 2765x aufgerufen. Wenn man das cachen könnte, wären schon alleine hier 40ms eingespart.
Ich hingegen glaube nicht, daß auf der dev-Mailingliste etwas passieren könnte - schließlich will ja OXID eSales AG auch die EE verkaufen, deren Hauptverkaufsargument das Caching ist…ich werde es aber dennoch versuchen.
Ich komme mit dem integrierten Profiler für _setFieldData auf 6-7% mit Demodaten, da sind allerdings auch nur ca. 1500 Aufrufe. Verkaufsargument für EE spielt glaube ich keine Rolle. In fast jeder neuen Oxid Version gibt es Performance verbessernde Maßnahmen, und das EE-Caching setzt ja an einer ganz anderen Stelle an.
