Hallo zusammen,
auf der Suche nach etwas mehr Performance ist mir aufgefallen das der grösste Teil der Querys die Oxid gegen die DB hämmert, die Parameter im Query String inkludiert, statt diese mit ? und array() zu übergeben wie auch in der Doku empfohlen wird.
Warum ist das so? Ich habe das im Moment nur für die Seo Zugriffe umgebaut, die ja nach meinem Verständniss die ersten DB Zugriffe sind bevor eine Seite geöffnet werden kann.
Für alle wiederkehrenden Querys macht das doch Sinn, wie seht ihr das? Hat sich daran schon mal jemand versucht?
Hi,
Auch wenn ich mich jetzt etwas unbeliebt mache
Die Community Version ist OpenSource.
Die Professional basiert auf der CE, bietet aber z.B. bereits ein zusätzliches Caching und Support
Die Enterprise basiert auf CE+PE und ergänzt Multishop ect.
Zu guter letzt gibt es noch die Oxid Professional Service, die gerne als Dienstleistung optimierungen speziell auf den jeweiligen Anwendungsfall verkaufen.
Mit Punkt 2 und 3 verdient Oxid Geld.
Die Punkte, die Du ansprichst, lassen die Möglichkeit, z.B. für Modulanbieter und Agenturen Geld auch mit der CE zu verdienen.
Ich persönlich benutze einen nicht zertifizierten Webserver, Redis-Caching und ein paar weitere Optimierungen.
Soviel ich weiss, hat Dein Anliegen noch niemand wirklich öffentlich umgesetzt. Du hast nun 4 Möglichkeiten:
A) nix machen und warten, bis jemand bei Oxid es umsetzt
B) als OpenSource Modul umsetzen und veröffentlichen
C) als ClosedSource Modul umsetzen und einer Zielgruppe, die es benötigt, verkaufen/lizensieren.
D) es umsetzen und Oxid einen PullRequest senden, damit es in den Core einfließen kann. Tests nicht vergessen
historisch gewachsen, würde ich sagen.
MySQL 4.1 mit dem damals neuen Feature “Prepared Statemens” kam Ende 2004 raus. Erfahrungsgemäß dauert es ein Paar Jahre, bis die Hoster auf “neue” Versionen umstellen.
Z.B. MySql 8 gibts seit über zwei Jahren. Profihost hat die Verfügbarkeit von MySQL 8 mit frühestens Februar 2020 angegeben, wobei es immer noch nicht in der Feature-Liste von deren Hosting Paketen aufgeführt ist, ich weiß also nicht, ob es jetzt verfügbar ist oder noch nicht.
Angenommen, MySQL 4.1 lief ab 2007 bei den Hostern, da gabs OXID eSales schon seit 4 Jahren.
Ich habe im Code der 6.2 bereits Anmerkungen gefunden, dass bestimmter Code in MySQL 8 nicht unterstützt wird und dieser nicht mehr verwendet werden soll. Es wird also irgenwann Support für MySQL 8 kommen und in diesem Zuge müssen die Queries dann sowieso aufgeräumt werden.
Bis dahin gibts einige Möglichkeiten: Caching, SSD Datenbank Server, mehrere DB Server
Danke für die Antworten. Werde mal an den aus meiner Sicht Performance kritischen Punkten die SQLs ersetzen. Werde berichten was es bringt, wenn es tatsächlich den Unterschied zw. CE, PE und EE ausmachen sollte, müsste man ja nur die suchen wo der Query Parameter extern deklariert wird.
So etwa:
$sQuotedSelectionId = oxDb::getDb()->quote($sSelId);
Seit 1998 entwickle ich Software, wenn Erweiterungen aus 2004 nicht im OXID umgesetzt sind, wo jeder der sich mit RDMS auskennt ne Ahnung hat was das für Meilensteine waren, dann ist das auch kein gutes Zeugnis für OXID, wenn bis heute nicht umgesetzt.
Jupp, kenn ich, der gilt aber nur für Leute/Firmen die nicht voran kommen wollen. Wenn ich erfolgreich sein will muss ich mich auch weiterentwickeln! Wie sieht das bei Dir, oder in Deutschland aus?
Gibt ja wenige Macher hier, @vanilla_thunder, habe deine Repos auf Git glaube alle gesehen. Super und viel Arbeit z.B. das Glow Theme, leider eingeschlafen aber es beinhaltet schöne Ansätze.
Für mich kommt es auf das Verhältnis zwischen der Entwicklung und der Nachbesserung (Bugfixes und Refactoring) an.
Weil ein Shop Upgrade immer viel Zeit und Geld kostet, wollen Händler auch schöne neue Funktionen haben, schließlich wird es kein Update geben, wenn der Händler es nicht will.
Ich kenne kaum einen Händler, der sofort ein Upgrade bewilligen würde, nur weil sein ITler einen aktuelleren Code haben will, da der aktuellere Code nicht mehr Brötchen auf den Tisch bringt, als der weniger aktuelle Code. Ich kenne auch nur Händler, die mindestens 4-5 Jahre mit dem selben Major Release unterwegs sind.
Früher hatte OXID ein ganz gutes Gleichgewicht zwischen Features und Berichtigungen+Verbesserungen, wie z.B. das responsive Flow Theme in dem 4.10 Release und auch deutliche Verbesserungen in der Erweiterbarkeit durch Module.
In den letzten ~2 Jahren gabs dagegen gefühlt nur noch solche “unsichtbaren Code-Verbesserungen” (Composer, Namespaces, Symfony, Services, DI ) und keine sichtbaren Features oder Verbesserungen (veraltete JavaScripts in Templates ersetzen, Cookie Richtlinie umsetzen), was m.M.n. falsch war. (weswegen ich auch ein entsprechendes Google-Review verfasst und daraufhin einen wütenden Anruf von der Marketing-Abteilung bekomen habe (streng genommen hat Marco den wütenden Anruf abbekommen, aber er hat es mit weiter erzählt ))
Und was glow angeht… Ich fange sehr bald ein neues Theme mit Bootstrap 5 an, hatte nur im letzten Jahr einen fiesen Job, bei dem ich täglich 16-18 Stunden unterwegs war und keine Zeit für Hobby-Projekte hatte. Aber jetzt habe ich wieder Zeit und freue mich schon darauf!
Coole Idee, wenn wir noch die Sprache ändern könnten wäre das eine Option, PHP gehört nicht wirklich zu meinen Favoriten, bin auf der Java Insel zu Hause.
Übrigens Grüße in die Alte Heimat.
Bringen die denn etwas? Wie testet du? Soviel ich weiß, wird doch die MySQL Verbindung zurückgesetzt, nachdem php-fpm den Task beendet hat. Demnach kein Vorteil sondern ein Nachteil, weil prepared Statements erst das System Anfragen und dann ausführen. D.h. du müsstest die Abfrage öfters durchführen, damit sie besser läuft. Aber es gibt noch einen riesen Nachteil von prepared Statements: du kannst diese nicht gut tracen und debuggen in MySQL
In PHP sehe ich damit keinen Vorteil. Korrigiert mich, wenn ich da was falsch sehe
Stellen wo Statements öfter verwendet werden, zum Aufbau einer Seite gibt es ja schon einige, als Beispiel der Aufbau der Kategorien. Das MySql die Prepared Statement nur für eine Verbindung nutzen kann, war mir neu, das ist in anderen Datenbanksystemen anders, bedeutet das man nur genau die ansehen muss, wo tatsächlich der gleiche Query in einer Schleife mehrmals ausgeführt wird.
Um nochmal die Kategorien anzusprechen, hier werde ich wohl mal testen ob man das nicht mit einem einzigen Query und einer erweiterten View in nur einem Select und ein wenig Programmcode abhandeln kann. Immerhin profitieren davon fast alle Shopseiten.
Grundsätzlich ist der Ansatz gut. Prepared Statements sind gerade für ein Shop System gut zu nutzen. Dass die PHP-FPM die Session schliesst, ist doch egal. Prepared Statements bedeuten, dass über die Abfrage ohne Parameterinhalt ein Hashwert gebildet wird und die ganzen Optimerungen durch den QueryPlan Optimizer ect. gespart werden.
Zusätzliche Views halte ich für Suboptimal. Es gibt es ganz andere Performance Optimierungen, die viel mehr Sinn machen, gerade, weil sich in einem ShopSystem in vielen Bereichen nicht permanent was ändert.
OK, wenn du uns noch verraten würdest welche du meinst?
Filesystem Caches sind nach meiner Meinung nicht viel besser wie ein Query mit gut gesetzten Indexes und ein wenig guten Programmcode. Andere Caching Techniken sind bei Shared Hosting ja kaum einsetzbar, aber ich lasse mich gern eines besseren belehren.
Der Shop mit ca. 20k Artikeln erreicht nach ein wenig Optimierung auf der Startseite in ca. 50% der Fälle 90 Punkte beim Pagespeed, auf Artikelseiten ohne weitere Empfehlungen und vile Crosselling Artikeln, im Mittel 93 Punkte. Gern würde ich aber sicher alles im Grünen Bereich sehen…
Ich habe nicht vor den ganzen Shop umzubauen und Caching ist kein gutes Mittel gegen verbesserungswürdigen Programmcode.
Damit möchte ich nichts gegen OXID sagen, auch heute bin ich der Meinung das es OutOfTheBox eines der bessten freien Systeme ist!
Ich bin ja selbst Entwickler und es ist klar das man bei der Entwicklung nicht mit 1 Mio Datensätzen testet und bei den Tests der Meinung ist, das alles super ist, dann fängt allerdings ab 500000 oder 1,5 Mio Datensätzen an die Performance ins Unterirdische zu kippen, dann muss man eben ran.
Auch kann man ja nicht erwarten das die CE Edition von Haus aus ein getunter F1 Mercedes ist
Eine Möglichkeit wäre, nebensächlichen Infos wie Crosselling, Zubehör etc aus dem ursprünglichen Rendering rauszunehmen und dynamisch nachzuladen. Diese werden sowieso als Widget gerendert, man braucht nur die nötigen url Parameter und schon kann man es nachladen.
Above the fold CSS würde auch ein paar Punkte bringen, ist aber deutlich komplizierter umzusetzen.
Ich würde auch unnötige Scripts ausmisten bzw. nur da laden, wo sie wirklich benötigt werden. Z.B. Amazon und Klarna Module haben (zumindest früher) jeweils zwei js Dateien und noch ein iframe auf jeder einzelnen Seite eingefügt, obwohl diese eigentlich nur im Checkout gebraucht wären.
Natürlich sind due Möglichkeiten bei einem Shared Hosting eingeschränkt. Da ist dann der erste Ansatzpunkt, weg vom Shared Hosting Richtung VPS oder Dedicated Server.
Dann lassen sich zusätzliche noch andere Sachen umsetzen.
Gruss
Marcel
Das bringt mich wieder auf das Glow Theme, nach kurzen Tests am Wochenende braucht es ja jquery-ui nur für die korrekte Verarbeitunger der Cookie Anzeige? Habe wirkltich nur oberflächlich geschaut aber im gesamten Bestellprozess und Admin nichts anders feststellen können.
))
bin ganz gespannt.
