Performance-Killer

Deutsches Forum
1

In einem Kunden-Shop, der auf einem schnellen Root-Server läuft, begannen sich die Responsezeiten bei zunehmender Füllung drastisch zu erhöhen, und lagen so bei 3,3 Sekunden.

Das eingeschaltete Debugging zeigte dann, dass 2,2 Sekunden davon (also 2/3!) in der Funktion “buildTree” verbraten wurden, die den Kategorienbaum aufbereitet.

Bei der Suche in den “Performance”-Optionen im Admin wurde die folgende Option

Kategoriebaum für die Suche laden (Die Suche kann auf einzelne Kategorien beschränkt werden)
als angewählt gefunden.

Nach Deaktivierung dieser Option “sprintet” der Shop jetzt wieder, die Responsezeit sank auf 0,9 Sekunden…

Was immer diese Routine macht: sie macht das irgendwie dramatisch falsch…

Sind nur 300 Kategorien im Shop.

Und negative Neben-Effekte der Deaktivierung sind bisher auch nicht aufgefallen.

Weiß jemand, was diese Option bewirkt, und warum das so lange dauert?

2

@avenger
Auch wenn Du meine Anfragen nicht beantwortest, hier doch ein Tip … :rolleyes:

Wenn diese Funktion aktiv ist erscheint bei der Artikelsuche ein zusätzliches Pulldown mit den Kategorien.

Guten Start in den Frühling …

3

[QUOTE=musicgate;27657]@avenger
Auch wenn Du meine Anfragen nicht beantwortest, hier doch ein Tip … :rolleyes:[/QUOTE]
Wie, wo, was???

Welche Anfragen???

[QUOTE=musicgate;27657]Wenn diese Funktion aktiv ist erscheint bei der Artikelsuche ein zusätzliches Pulldown mit den Kategorien.[/QUOTE]

Ach, das ist das…

Aber warum der Shop dafür so viel Zeit verbrät…

Darauf sollte man also besser verzichten.

4

Auf jeden Fall ist das schon lange ein “Performance Killer”. Aus dem alten Forum:

30.10.2005, 14:48
Benutzerbild von Eric Jankowfsky
Hi
mach mal im Reiter Performance das Häckchen bei “Kategoriebaum für die Suche laden” raus. Wirst sehen, das sind Welten was die Geschwindigkeit angeht.
Eric

–
Eric Jankowfsky

Für den Kunden macht das Häckchen doch genau das, was beschrieben ist. Wenn es deaktiviert ist kann der Kunde seine Suche nicht mehr auf eine Kategorie einschränken. … Das Pulldown verschwindet.

CYA

5

[QUOTE=avenger;27658]Wie, wo, was???

Welche Anfragen???
[/QUOTE]

Anfrage über Kontaktformular auf Deiner Seite und als PN hier im Forum. Betrifft Offertanfrage zu Shopgestaltung. Vielleicht liegt es daran, dass alle Oxid-Partner vor Aufträgen den Wald nicht mehr sehen oder so … :slight_smile: Falls nicht, sende mir doch eine Mailadresse als PN.

6

Jo die funktion kann echt etwas auf die performance drücken, zumal man für css dropdown menüs ohne javascripteinsatz die option zwingend braucht. das witzige ist ja, das der kategoriebaum schon ein nested set ist, also eigentlich schon schnell sein müsste und der kategoriebaum auch im dateisystem gecached wird.

ich glaube langsam das prinzip der einzigartigen “OXID” für den ganzen IDs schon ist in die jahre gekommen, und man täte besser sich auf foreign keys und numerische ids zu verlassen. Das ist aber eher was für OXID 5.

7

Eine Frage an die Shopbetreiber zu dem Thema:

[B]Glaubt Ihr, dass diese Funktion von Kunden tatsächlich genutzt wird ? [/B]
In Shops mit wenigen Kategorien vielleicht. Aber wie in Avangers Fall (300 Kategorien) oder bei mir ca. 220 Kategorien ist das doch so unübersichtlich, dass ich ja als Shopbetreiber schon meine Probleme habe dort etwas zu finden.

8

diejenigen, die das filtern “erleichtern” wollen, nutzen doch zum größten teil celebros, factfinder oder eigen entwickelte filter

9

[QUOTE=csimon;27661]Jo die funktion kann echt etwas auf die performance drücken…[/QUOTE]
“Etwas” ist gut… :smiley:

Eine Verdreifachung der Responsezeiten ist definitiv zu viel.

Das Problem scheint mir zu sein, dass hier der Kategorienbaum mit allen Objekten und ihrem ganzen Rattenschwanz an Daten und Code erstellt wird, wo man eigentlich für den gewünschten Zweck für jeden Eintrag nur Kat-Namen, Kat-Link und. evtl. ein Kat-Level brauchen würde…

Am besten wäre m.E. natürlich, wenn man das Ding gleich komplett als “ul/li”- oder “select”-Struktur bekäme…

[QUOTE=csimon;27661]…, zumal man für css dropdown menüs ohne javascripteinsatz die option zwingend braucht.[/QUOTE]
Das ist natürlich dann blöd…

Wie würde Javascript helfen, das anders zu lösen?

10

Naja, du lädst halt alles per asynchronem request nach, das ist aber auf deutsch gesagt scheisse weil die kategorielinks dann nicht auf der seite sind und bei lahmen responsezeiten des servers eventuell die kategorien nicht einwandfrei navigierbar sind.

In Shops mit wenigen Kategorien vielleicht. Aber wie in Avangers Fall (300 Kategorien) oder bei mir ca. 220 Kategorien ist das doch so unübersichtlich, dass ich ja als Shopbetreiber schon meine Probleme habe dort etwas zu finden.

Es wird ÜBERALL da genutzt wo du dropdown kategorienavis hast. Ausserdem ist es eventuell sogar besser für google, weil dann die kategorielinks auf jeder seite zu finden sind und er quasi nur die startseite crawlen muss um alle kategorien zu haben.

11

Ich meine, wir haben es hier mit einem echten Bug zu tun.

Und deshalb einen Bug-Report erstellt…

https://bugs.oxid-esales.com/view.php?id=1713

12

Auch die Option “frisch eingetroffen” ist bei vielen Artikeln ein echter Performance Killer…

13

[QUOTE=avenger;27654]Das eingeschaltete Debugging zeigte dann, dass [B]2,2 Sekunden[/B] davon (also 2/3!) in der Funktion “[B]buildTree[/B]” verbraten wurden, die den Kategorienbaum (für die Suche) aufbereitet[/QUOTE]
Nachdem sich das Aufbereiten des Kategorienbaums für die Suche (der in ähnlicher Form ja auch für horizontale und vertikale CSS-Flyout- oder Tabbed Menüs benötigt wird) in der Standard-OXID-Form ja als [B]ganz übler Performance-Killer [/B]herausgestellt hat, den man eigentlich gar nicht Einsetzen kann, habe ich mal überlegt, wie man das ändern kann…

Ich habe mich nämlich in letzter Zeit intensiv mit den diversen einschlägigen jQuery-Plugins beschäftigt, um unsere Shops damit weiter “aufzupeppen”, und die benötigen halt alle den kompletten Kategorienbaum…

Mit dem jetzt gezeigten Zeitverhalten wäre das aber in Praxis nicht mehr verwendbar gewesen!

Aber getreu meinem 3. Wahlspruch “[B]Was nicht passt, wird passend gemacht.[/B]” konnte ich das einfach nicht akzeptieren, und habe deshalb nach besseren Alternativen gesucht!

Da ich das Problem darauf zurückführte, dass hier (für den angestrebten Zweck völlig überflüssigerweise!) der Kategorien-Baum das ganze “[B]Objekt-Gedöns[/B]” enthält, war meine erste Idee, das alles zu vergessen, und den Kategorienbaum [B]direkt [/B]aus dem Inhalt der “[B]oxcategories[/B]”-Tabelle aufzubauen. (So wie xtCommerce das macht…)

[B]Ergebnis: das funktioniert prächtig und mit einer [U]unglaublichen[/U] Zeitersparnis![/B]

Ich habe mit meiner neuen Routine die Kategorien-Auswahlbox für die Suche mit den Daten des gleichen Kundenshops nach gebaut (wobei ich kein Template mehr verwende, um die Auswahlbox zu rendern, sondern das direkt wesentlich effizienter mache).

Hier das geniale Resultat:

[B]Time elapsed: 0.127586126328 seconds for 379 categories.[/B]

Statt [B]2,3[/B] Sekunden werden also jetzt nur noch [B]0,13[/B] Sekunden für den Aufbau der Kategorien-Auswahlbox “verbraten”, dieses Verfahren ist also [B]17 mal [/B]schneller als das Standard-OXID-Verfahren!

Unter http://www.powertemplate.de/kunden/oxid/info/categories_timing.html habe ich meine Testausgabe-Seite bereit gestellt.

Da ist zum einen die Kategorien-Auswahlbox für die Suche drin, zum anderen auch noch eine direkte Darstellung der Kategorien-Struktur…

Jetzt kann ich also getrost meine jQuery-Menü-Träume weiter verfolgen…

(Wozu ich allerdings die Menü-Struktur noch als “[B]ul/li[/B]”-Liste aufbereiten muss.)

Man sieht:

machmal ist das ganze "[B]Objekt-Gedöns[/B]"doch ein massiver und zeitraubender Overkill, und weniger ist hier mehr.

Man verliert zwar die der Standard-OXID-Lösung innewohnende Flexibilität, aber um eine Kategorien-Dropdown-Box aufzubauen brauche ich das ja nicht unbedingt…

14

Hier das geniale Resultat:

Time elapsed: 0.127586126328 seconds for 379 categories.

Statt 2,3 Sekunden werden also jetzt nur noch 0,13 Sekunden für den Aufbau der Kategorien-Auswahlbox “verbraten”, dieses Verfahren ist also 17 mal schneller als das Standard-OXID-Verfahren!
Bei den Zeitmessungen ist mir so auf die schnelle ein schwerer gedanklicher Fehler unterlaufen:

ich habe nämlich die Zeit für den Aufbau des Kategorien-Baums auf dem Kundenserver (2,3 Sekunden) verglichen mit der Zeit des neuen Verfahrens auf meinem lokalen Rechner (0,13 Sekunden)!

Auf meinem Rechner benötigt der Aufbau des Kategorien-Baums mit dem OXID-Standard-Verfahren aber ganze 6.9 Sekunden, also 3 mal so lange wie auf dem Kundenserver! (Muss mir wohl mal einen neuen Rechner gönnen!)

Das bedeutet aber im Klartext:

das neue Verfahren ist nicht nur 17 mal, sondern glatte 50 mal(!!!) schneller, als das Standard-Verfahren!

Was natürlich richtig spannend ist!

Ich habe der “oxcategories”-Tabelle noch einen weiteren Index spendiert (über “oxtitle”), damit lassen sich weitere 10% Zeit einsparen.

Bei sogar etwas verbesserter Leistung (die Haupt-Kategorien werden in der Auswahlbox als “optiongroup” optisch hervorgehoben…).

Das Erstellen der Kategorien-Auswahlbox ist aber nur ein Aspekt bei der Erstellung des kompletten Kategorienbaums.

Für fortgeschrittene Menü-Lösungen (Flyout- und Tabbed-Menüs) benötigt man zusätzlich für jede Kategorie den (SEO-)Link, sowie die Zuordnung aussagefähiger CSS-Klassen, um die Menüeinträge gezielt “stylen” zu können.

Bei den SEO-Link ergibt sich jetzt aber das Problem, dass die vorhandenen Methoden zur Ermittlung der Links von einem vorhandenen Kategorien-Objekt ausgehen, was aber jetzt nicht mehr vorhanden ist!

Konsequenz: um hier zum Ziel zu kommen, musste ich die SEO-Links auch direkt aus der Datenbank ermitteln.

Mit Erstellung der Links und CSS-Klassen ergibt sich dann das folgende Ergebnis:

Time elapsed: 0.258759975433 seconds for 379 categories.

D.h., die Zeit für die Erstellung des kompletten verlinkten Menübaums steigt um ca. 0,13 Sekunden…

Die Testausgabeseite für diesen Fall findet sich hier: http://www.powertemplate.de/kunden/oxid/info/categories_timing_link.html

Für das OXID-Standard-Verfahren gibt es dafür erst mal keine direkte Vergleichszeit, da ein verlinkter Kategorien-Baum nicht erstellt wird…

Daher habe ich in das Template zum Aufbau der Kategorienauswahlliste ein “[{assign var=“link” $ocat->getLink()}]” eingefügt, um die Linkberechnung zu erzwingen…

Die gesamte Ausführungszeit erhöhte sich dabei um ca. 0,2 Sekunden.

Das neue Verfahren hat dafür ca. 0,13 Sekunden mehr gebraucht, so dass das auch hier ca. 30% schneller ist…

15

Man sieht, dass es doch oft sinnvoll ist, einiges der Logik an die DB auszulagern und nicht alle Daten zu laden, um diese dann auf dem Webserver wieder auszusieben. Natürlich ist es immer eine Gradwanderung zwischen wenig DB Zugriffen und Datenmenge, die man lädt. Aber Grundsätzlich würde ich sagen, daß man lieber einmal zuviel auf die DB Zugreift, als riessige Mengen von Daten mit der PHP Engine zu verarbeiten.

16

[QUOTE=imd;27778]Aber Grundsätzlich würde ich sagen, daß man lieber einmal zuviel auf die DB Zugreift, als riessige Mengen von Daten mit der PHP Engine zu verarbeiten.[/QUOTE]

Hi,

da gebe ich Dir recht, aber werf mal den Debug-Mode 7 an, und Du wirst sehen, dass Oxid leider keineswegs vermeidet, einmal zuviel auf die Datenbank zuzugreifen.

Wenn ich der Hersteller wäre, würde ich für die Version 5 hier jemanden ransetzen, mit dem Auftrag, SQL-Abfragen sowie die darauf folgende Verarbeitung der Daten in den PHP-Objekten zu minimieren. Vermutlich müßte man dafür vielleicht an der einen oder anderen Ecke Abstriche bei der Objektorientierung machen, aber es würde sich sehr lohnen.

Daß die meisten Seitenaufrufe mindestens 850 ms brauchen (wenn es schnell geht…), bis der Server eine Antwort liefert, ist leider nur noch gerade so akzeptabel. Richtig schnell ist das nicht - wäre aber bestimmt auf die Hälfte zu reduzieren.

Ich bin ganz zuversichtlich, daß das Entwicklerteam das hinkriegt.

Schöne Grüße,
Achim

17

Und so schwindet mit der Performance der wesentliche Vorteil von Oxid zu Magento …

18

[QUOTE=imd;27806]Und so schwindet mit der Performance der wesentliche Vorteil von Oxid zu Magento …[/QUOTE]

Ich glaube, da hat Oxid bisher aber noch einen dicken Vorsprung, und der ist sicher noch ausbaubar.

Aber im Moment liefert zB der Zend Benchmark einen Wert von 1,3 requests/sec, den der Oxid Demoshop verarbeiten kann. Für die meisten Shops draußen reicht das wohl, aber so richtig performant ist es (noch) nicht.

Werte für Magento kenne ich nicht, als ich mir das aber mal angeschaut hab, war alles quälend langsam.

19

[QUOTE=imd;27806]Und so schwindet mit der Performance der wesentliche Vorteil von Oxid zu Magento …[/QUOTE]
Der wesentlich Vorteil von OXID gegen Magento ist nicht nur Geschwindigkeit, sondern vor alem die wesentlich einfachere Erweiterbarkeit und das Templating.

Da liegen Lichtjahre zwischenMagento und OXID.

20

Von einem Performance Vorteil zwischen Oxid und Magento zu reden ist doch ehrlich gesagt absurd - unser guter alter Oxid Shop läuft selbst auf einem shared host noch (wie ist eine andere Frage), zudem brauchst du nicht eine Kompanie von Proggern um Oxid umzubauen wie Avenger schon sagte.