Bei allgemeinen Shop-Systemen, CMS, Foren-Software etc. muss die Software Memcached unterstützen. Erkundigen Sie sich dazu am Besten beim Softwarehersteller.
Wie sieht es mit OXID CE - PE aus? Unterstützt OXID memcache ?
Wäre für Artikel sicherlich sehr gut aber im Warenkorb suboptimal?
danke für die Antwort.
Wenn Ihr da was macht gehe ich mal davon aus, dass es dann auch in den Release-Notes steht. Dann reicht es ja wenn es auf dem Server auch erst dann installiert wird
Ich wollte zu dem Thema noch mal nachhaken. ich setze die oxid Version 4.4.5 ein. Wird hier memcache unterstützt? Mein Provider hat mir die Info gegeben, dass man das aktivieren könnte. Danke für eine kurze Info.
Ich wollte zu dem Thema noch mal nachhaken. ich setze die oxid Version 4.4.5 ein. Wird hier memcache unterstützt? Mein Provider hat mir die Info gegeben, dass man das aktivieren könnte. Danke für eine kurze Info.
Freundlicher Gruß
SCHORTY[/QUOTE]
Hallo,
auch wenn die Frage nicht man mich ging, kurz meinen Stand (da Marco ja noch im Urlaub ist).
Memcache ist in Arbeit abernoch nicht implementiert und steht, soviel ich weiß, auf der Roadmap für die 4.6.
also ich habe vor einiger Zeit mal einen Shop mit memcache ausgestattet,
das ging prinzipiell so dass ich statt adodblite adodb nahm, und dann in den core
methoden sowas wie folgendes:
(so bleibt es unschaltbar, und man kann halt im Zweifel schnell bei Problemen umschalten auf Standardverhalten und auch die betreffenden Zeilen finden …)
eingebaut hatte, dann übernimmt ADODB das Caching (nach Konfiguration versteht sich) automatisch.
Das hat zwar schon einiges gebracht, aber sicherlich ist es weit sinnvoller das Caching auf Objektebene zu machen als so …
Verstehe ich das richtig, dass ich im gesamten Core dann alle executes umbauen muss. Dann ist das Thema Update absolut erledigt. Das kann ja nicht der Weisheit letzter Schluss sein, oder?
Ich hab da mal kurz zu gegoogelt, aber nicht wirklich was gefunden: wie muss ich mir denn ein Caching auf Objektebene vorstellen?
Hallo,
naja der Weisheit letzter Schluss ist es sicherlich nicht, ein Refactoring der wenigen Perfomance relevanten ->execute Methoden für ein Update sollte jedoch kein übergrosses Hindernis darstellen.
Auf Objektebene stelle man sich das so vor:
Innerhalb der Klassen müssen diw DB Performanceschuldigen gefunden werden, z.B. bei vielen Varianten, das erzeugen derer, anstatt dann in memcache das SQL zu cachen, dann in memcache objektname_methode_oxid => resultat speichern, und das dann abfragen, bzw. wenn nicht vorhanden speichern.
Auf diese Art müsste man nur wenige Methoden erweitern, und wäre dann update sicher …
das hört sich doch schonmal einigermaßen interessant an. Man könnte also quasi ein MemcachedPerformance-Modul schreiben. Hat jemand zufällig aus einem eigenen Projekt schon eine anfängliche Liste, welche Methoden da relevant sein könnten?
Wo ich mir ein bisschen Gedanken mache ist der folgende Punkt: wie stelle ich sicher, dass gecachete Objekte auch gelöscht werden, wenn nötig. Da Oxid ja nicht nur via Objekt in die DB schreibt, sondern z.B. auch gewisse Zuordnungen (Listen im Backend) direkt per SQL schreibt, könnte ich mir vorstellen, dass eine sichere Löschung der Objekte bei Änderungen nicht ganz trivial ist. Was mein Ihr dazu?
[QUOTE=Rubas;108339]
Würde hier gerne den Turbo zünden ;)[/QUOTE]
Hallo,
was spricht gegen eine EE? Die reinen Kosten?
Wir haben ja ein Performance-Monster hinter uns. Die Erfahrung die wir gemacht haben: Pauschal hilft da recht wenig. Schnell wird es, wenn du deine Bremsen benennen kannst und die konkret löst.
Ist die Datenbank wirklich die Bremse? Wenn ja: Welche Stelle? Welche Query?