ADODB Caching verwenden

[B]Achtung, das ist nichts für schwache nerven - wer nicht weiß was er hier tut der lässt es lieber![/B]

Hier ein kleiner proof-of-concept wie man das query caching mit einem kleinen Hack in Oxid aktivieren kann (getestet und funktioniert unter CE 4.5.5 und 4.4.8):

[ul]
[li]ADODB herunterladen => http://sourceforge.net/projects/adodb/files/latest/download?source=files
[/li][li]Archiv entpacken und hochladen in den core Ordner, danach solltet ihr einen Ordner core/adodb5 haben
[/li][/ul]

So nun geht der eigentliche Hack los, das ginge sicherlich auch irgendwie mit einem Modul, aber dazu bin ich gerade nicht motiviert:

core/oxdb.php öffnen, oben ändern:


// Including main ADODB include
require_once getShopBasePath() . 'core/adodb5/adodb.inc.php';

speichern, hochladen.

So nun noch dafür sorgen dass auch etwas gecached wird, fangen wir mit allen oxlist Objekten an:

core/oxlist.php öffnen und suchen:


 if ( $this->_aSqlLimit[0] || $this->_aSqlLimit[1]) {
            
            $rs = oxDb::getDb(true)->SelectLimit( $sSql, $this->_aSqlLimit[1], $this->_aSqlLimit[0]);
        } else {
            $rs = oxDb::getDb(true)->Execute( $sSql);
        }

Ersetzen durch:


 if ( $this->_aSqlLimit[0] || $this->_aSqlLimit[1]) {
            
            $rs = oxDb::getDb(true)->CacheSelectLimit( $sSql, $this->_aSqlLimit[1], $this->_aSqlLimit[0]);
        } else {
            $rs = oxDb::getDb(true)->CacheExecute( $sSql);
        }

Das funktioniert soweit im Frontend ganz gut, eventuell sollte man das im Admin Bereich lieber sein lassen - friemelt euch das selber raus.

Das ganze kann man jetzt noch erweitern für die oxbase Objekte, dazu muss man halt die Executes durch CacheExecute in core/oxbase.php ändern.

Hallo,
klingt interessant. Habt ihr das mal unter Last gemessen? Wieviel Power ist dadurch zu erwarten?

Gruß Joscha

Nunja, man muss immer sehen wie man es angeht. Für kleinere Shops mit wenigen Artikeln/Kategorien ist das eher weniger interessant denn adodblite ist von Haus aus performanter als adodb an sich. Wenn man aber einen großen Brocken Artikel schaufeln muss dann lohnt es sich schon (subjektiv im Moment, Ergebnisse folgen). Wirklich interessant wird es wenn man einen memcache server (oder mehrere) verwendet und die dann in den adodb caching settings setzt - dann bringt es wahrscheinlich bei jedem Setup eine Steigerung. Ich würde es einfach probieren wenn man die Last auf der Datenbank runterfahren will, einfach gucken was passiert - wenn man es richtig macht dann kann auch nichts kaputt gehen.

Warum ändert Ihr nicht die “SelectLimit”- und “Excecute”-Methoden mit ihren “Cache”-Varianten?

Dann hätte man das doch gleich für alles verfügbar.

Also bei Execute hätte ich ein bisschen Angst was passiert bei Update/Delete etc. - für SelectLimit wäre es sicher noch sinnvoll. Wie würdest du es angehen?

[QUOTE=aggrosoft;76021]Also bei Execute hätte ich ein bisschen Angst was passiert bei Update/Delete etc. - für SelectLimit wäre es sicher noch sinnvoll. Wie würdest du es angehen?[/QUOTE]
Evtl. nur wenn es ein “SELECT”-Query ist automatisch umsetzen?

Also, das eingebaute caching scheint doch so einiges zu zerstören - das meiste davon im admin. Ich denke es ist sinnvoller da auf basis von adodblite etwas weiter zu entwickeln, frage ist halt wieviel es bringt - wenn schon der adodblite Entwickler sagt dass Caching manchmal langsamer ist als direkt auf SQL Ebene zu arbeiten.