Performance Oxid Api

Hi zusammen,

ich lese mittels einem PHP Script alle Varianten aus, welche zu einem Artikel gehören und bastel mir daraus ein JSON Objekt zusammen. Funktioniert soweit alles bestens. Nur wollte ich jetzt mal die API verwenden und hab mir dafür eine eigene View erstellt. Das funktioniert auch soweit bestens und das JSON Objekt wird auch erstellt.

Allerdings ist die Performance mit der API wesentlich schlechter als mit meinem vorher verwendeten PHP Script ohne auf die OXID API zuzugreifen, so dass ich jetzt wieder das alte Script einsetzen.

Hab ehrlich gesagt keinen Schimmer, weshalb die Performance bei Verwendung der API so einbrachte. Sprich, die Requests benötigen ca. 200 ms länger, was sich natürlich auf die Bedienung im Frontend merklich auswirkt.

Der View besteht lediglich aus zwei Funktionen, 3 einfachen SQL Statements und zwei WHILE Schleifen, also kein Hexenwerk.

Was lässt denn bitteschön die Performance so einknicken?

Gesendet von meinem HTC Vision mit Tapatalk

Welche API-Funktionen genau verwendest Du denn?

Setze doch mal iDebug auf 3, dann sieht man ja, was da alles geschieht.

Okay, teste ich dann, sobald ich Zuhause bin.

Benutze nur die oxDb Funktionen für die Db Connection und daraufhin die Execute Funktionen, sowie in den while-Schleifen dann EOF und innerhalb der Schleifen dann die next Funktion. Also wirklich nix Besonderes.

Gesendet von meinem HTC Vision mit Tapatalk

Und was hast Du vorher gemacht?

Wenn Du das API aktivierst, dann wird ja m.E. viel mehr, als nur oxDB aktiviert…

Nur die oxubase extended, dann hab ich ja schon alles. Also class getvariants extends oxubase. Vielleicht too much?

Gesendet von meinem HTC Vision mit Tapatalk

Wenn Du mit oxDB da selbst Hand anlegst brauchst Du ja sonst nichts.

Aber schau mal was Dir der Debugmodus liefert

Ja, ich fackel mit oxbd nur 3 einfache Queries ab in mach dann nach dem Erstellen ein echo encode_json($json) nachdem ich mir das Array erstellt hab. Mehr ist das net. Oder sollte man ne andere Klasse erweitern? Ich brauch ja wirklich nur oxDb und die adodb Synt x, fertig ist der Anstrich.

Gesendet von meinem HTC Vision mit Tapatalk

Die Ursache ist (ziemlich wahrscheinlich): in oxubase werden Components initialisiert:


    protected $_aComponentNames = array(
                                    'oxcmp_user'       => 1, // 0 means dont init if cached
                                    'oxcmp_lang'       => 0,
                                    'oxcmp_cur'        => 1,
                                    'oxcmp_shop'       => 1,
                                    'oxcmp_categories' => 0,
                                    'oxcmp_utils'      => 1,
                                    'oxcmp_news'       => 0,
                                    'oxcmp_basket'     => 1
                                  );

Du kannst in deinem View einfügen:


	protected $_aComponentNames = array();

Dann läuft das wieder mit Full Speed!

Hi Frank, hi Avenger,

so, jetzt habe ich gerade mal das hier eingebaut:


class getvariants extends oxUBase
    { 
        
        protected $_aComponentNames = array();  
        
        public function render()
        { 
               
        $colorPosition = oxConfig::getInstance()->getShopConfVar("colorPosition", $sShopId = null );
        $varThumbSize = oxConfig::getInstance()->getShopConfVar("varThumbSize", $sShopId = null );
        $varProductSize = oxConfig::getInstance()->getShopConfVar("varProductSize", $sShopId = null );
        $varZoomSize = oxConfig::getInstance()->getShopConfVar("varZoomSize", $sShopId = null );
                 
        $dbxparentid = oxDb::getDb()->qstr('' . $_POST['id'] . '');
        
        $sSelect = "SELECT oxartnum, oxvarselect FROM oxarticles WHERE oxparentid = " . $dbxparentid . " AND oxactive = '1' ORDER BY oxsort";
        $rows  = oxDb::getDb(true)->Execute($sSelect);      

Ein klein bißchen schneller isses geworden, aber an die Script Pure Variante kommts immer noch nicht hin. Der Farbwähler laggt so also noch ein bißchen. Gibts sonst noch irgendwas, was hier sein könnte, bzw. an welcher Schraube man noch drehen könnte, damit die Geschwindigkeit wirklich auf Full Speed ist. Oder ist OOP generell etwas langsamer?

Ich denke eher nicht das es am OOP liegt sondern daran dass der ganze Shop erstmal gestartet werden muss - ein ORM Framework ist in den seltensten Fällen schneller als ein kleines Script dafür.

Du kannst das noch ein bisschen beschleunigen indem du das MVC ganz weglässt und das Framework direkt im File startest:

function getShopBasePath() {
    return dirname(__FILE__) . '/';
}
require_once getShopBasePath() . 'core/oxfunctions.php';
$myConfig = oxConfig::getInstance();
$oDb = oxDb::getDb();

Aber ohne Framework ist sicher immer schneller.

Hi zusammen, das heißt aber dann, das ich die View Klasse überhaupt nicht mehr benötige, oder?

Ich verzichte jetzt also meine View-Klasse und baue die oben genannten Funktionen in mein bisheriges Script ein um die oxDB zu nutzen. MyConfig kann ich ja verwenden, wies gerade immer noch der Fall ist… Jedenfalls bräuchte ich dann die DB nicht nochmals extra initialisieren.

Vielen Dank erstmal für Eure Antworten :slight_smile:

[QUOTE=coarsy;81844]Hi zusammen, das heißt aber dann, das ich die View Klasse überhaupt nicht mehr benötige, oder? [/QUOTE]
Ja mit view-Klasse wäre MVC über die index.php, im Beispiel oben wird dann die Datei direkt aufgerufen und liegt im Rootverzeichnis.

Okay, hab mich jetzt für die Lösung ohne MVC entschieden, ist genauso schnell wie das stinknormale Script und verwendet die Einstellungen aus Oxid heraus, super, ich danke Dir :slight_smile: :slight_smile:

Noch eine kleines Anliegen bitteschön:

Mit


require_once getShopBasePath() . 'core/oxfunctions.php';

In einer weiteren Funktion muss ich das ja nochmal tun, da das
ja innerhalb der nächsten Funktion nich mehr gilt. So
würde ich gerne oxDb::getDb() in eine Variable schreiben und an die
Unterfunktionen mit übergeben.

Nur habe ich Stellen, an denen ich in oxDb::getDb(true) das true benötige. Besteht
also die Möglichkeit das true irgendwie anderweitig zu setzen? So wie ich das verstanden habe, wird das true dann benötigt, wenn man durch mehrere rows durchhampeln möchte.

Okay, vergesst es einfach :slight_smile: Habs mal mit zwei Variablen probiert, mehr Performance geht net mehr :wink: Jedenfalls ist jetzt alles im Shop modular umgsetzt, auch die Farben innerhalb der Listenansicht ist nun als Modul installiert. Prima, jetzt muss ich im DEV-Shop nicht jedesmal die Datenbankconnections überall nachtragen. So solls sein und wieder einiges gelernt :slight_smile: