ich versuche nun schon seit einer Woche den Shop eines Kunden zu optimieren und komme einfach nicht auf einen grünen Zweig.
Der Shop ist auf dem aktuellen Stand (CE 4.4.4), der Löwenanteil von gut 35k Artikeln liegt in einer Hauptkategorie mit ca. 40 Unterkategorien, pro Kategorie also zwischen 500 und 2000 Artikeln. Schon das reine Aufrufen der Hauptkategorie-Startseite die nichts außer den Links zu den Unterkategorien enthält, dauert ca 1.5 Sekunden - soweit ich das aus dem Performance Log sehen kann, ist hier die Funktion getCategoryUri mit 50% Zeitanteil der Hauptschuldige - durch die verschiedenen Navigationsmöglichkeiten wird diese ca 250x aufgerufen.
Geht man dann auf eine Artikelseite wirds noch schlimmer - 4 bis 5 Sekunden für einen normale Seite sind der Durchschnitt, nutzt man die Suchfunktion haben wir Zeiten von 15 Sekunden und mehr.
An den Queries hab ich schon optimiert, das sehr komische ist, das mir der Profiler teilweise nicht anzeigt wo die Zeit herkommt, die höchste Einzelposition ist dann “loadinglists” mit ca 15 bis 20% was von der Zeit durchaus ok ist - aber wo sind die anderen 15 Sekunden hin?
Die Leistung der Plattform ist ansonsten ganz ok, getrennte DB/Web Server, keine sichtbaren Load-Spitzen oder Waits. Selbst auf meiner lokalen Workstation wo sonst nichts anderen läuft brauchen die Queries noch 6 bis 8 Sekunden.
Hat irgendjemand vielleicht eine Idee an welchen Einstellungen auf DB oder PHP Seite man noch drehen kann?
[QUOTE=oliwel;42929]
An den Queries hab ich schon optimiert, das sehr komische ist, das mir der Profiler teilweise nicht anzeigt wo die Zeit herkommt, die höchste Einzelposition ist dann “loadinglists” mit ca 15 bis 20% was von der Zeit durchaus ok ist - aber wo sind die anderen 15 Sekunden hin?[/QUOTE]
Der Profiler zeigt nur die Blöcke an, bei denen Profiling im Code steht. Du könntest selber Profiling-Blöcke erstellen:
startProfile("meinProfil");
//codeblock der geprüft werden soll
stopProfile("meinProfil");
Vielleicht kommst du dann den Sekunden auf die Spur.
Haken bei: Kategoriebaum für die Suche laden gesetzt oder nicht ? Der soll sehr auf die Performance gehen Du kannst ja mal hier schauen kommt von avenger und ist sehr hilfreich.
Ich kämpfe auch gerade an dem Thema, wenn du eine Lösung gefunden hast immer her damit.
danke für die schnellen Antworten nur ist da leider nix Neues dabei. @leofonic: Ich hab schon an diversen Stellen Profiling Punkte eingebaut, habe aber eben nichts wirklich auchmachen können das ein “Showstopper” ist.
Die Optimierung der Volltextsuche durch eine eigene Cache-Tabelle wie in der csimon vorgeschlagenen Powerpoint habe ich schon hinter mir und die anderen Tipps bezüglich Laden und Cachen von Medien sind ja nicht das Problem. Nicht das Laden der Medien dauert sondern der Aufbau der Hauptseite ist das Problem.
Bei vielen Kategorien/Produkten zeigt sich der Nachteil der Objektorientierung, weil immer (auch wenn gar nicht benötigt) die Objekte komplett erstellt und geladen werden (geht auch mächtig auf den Speicher).
Die bessere Lösung ist sicher, die Katbäume direkt aus der Datenbank zu generieren, das geht um den Faktor 50 schneller.
[QUOTE=Sven39;42941]
Haken bei: Kategoriebaum für die Suche laden gesetzt oder nicht ?
[/QUOTE]
Nein der ist aus - wir haben zwei unterschiedliche Kategorie-Listings auf der Seite (Hauptnav und Subnav) aber ich werde den Tipp mit dem direkten DB Zugriff mal versuchen.
bldöe Frage - ich hab jetzt einfach im _left.tpl den Category Code rausgenommen und im oxShopControl mal den Baum reingepackt - gibts ne bessere Stelle, evtl so das man Update-Fähig bleibt. Direkt aus Smarty raus komme ich ja afaik nicht an die DB oder?
Für alle Spätleser - Nachdem sich die Kategorien beim Kunden so gut wie nie ändern, hab ich es nun so gelöst:
Der Gesamte Baum links wird als statisches HTML eingebunden, die nicht verwendeten Unterkategorien werden per jQuery ausgeblendet und wenn der Kunde was aktualisiert gibt es ein kleines Skript das den Baum neu berechnet.
[QUOTE=oliwel;43649]Für alle Spätleser - Nachdem sich die Kategorien beim Kunden so gut wie nie ändern, hab ich es nun so gelöst:
Der Gesamte Baum links wird als statisches HTML eingebunden, die nicht verwendeten Unterkategorien werden per jQuery ausgeblendet und wenn der Kunde was aktualisiert gibt es ein kleines Skript das den Baum neu berechnet.[/QUOTE]
Cookies haben damit gar nix am Hut, die aktive Kategorie wird vom Shop an die Templates übergeben. Ohne Javascript sieht der Kunde halt die Kategorien alle ausgeklappt. In dem Falle nicht tragisch da nur eine Kategorie Unterpunkte hat, notfalls kann man das Spielchen ja für jeden Teilbaum extra machen.
[QUOTE=oliwel;43676]Cookies haben damit gar nix am Hut, die aktive Kategorie wird vom Shop an die Templates übergeben. Ohne Javascript sieht der Kunde halt die Kategorien alle ausgeklappt. In dem Falle nicht tragisch da nur eine Kategorie Unterpunkte hat, notfalls kann man das Spielchen ja für jeden Teilbaum extra machen.
[QUOTE=oliwel;43676]Cookies haben damit gar nix am Hut, die aktive Kategorie wird vom Shop an die Templates übergeben. Ohne Javascript sieht der Kunde halt die Kategorien alle ausgeklappt. In dem Falle nicht tragisch da nur eine Kategorie Unterpunkte hat, notfalls kann man das Spielchen ja für jeden Teilbaum extra machen.
Schön das Cookies nix mit den Links des Kategoriebaums am Hut haben.
Noch besser ist, dass der Warenkorb geleert wird, bzw. man die Session verliert, wenn man Cookies deaktiviert hat und auf den Kategoriebaum klickt.
Diese Navigationsform halte ich für gewöhnunsbedürftig, ehrlich gesagt. Die Farbe der Buttons etc. sollte auch nochmal überdacht werden. PS: Der Bilderzoom ist defekt.
[QUOTE=MBa;43701]Schön das Cookies nix mit den Links des Kategoriebaums am Hut haben.
Noch besser ist, dass der Warenkorb geleert wird, bzw. man die Session verliert, wenn man Cookies deaktiviert hat und auf den Kategoriebaum klickt.[/QUOTE]
[QUOTE=ChristophH;43704]Diese Navigationsform halte ich für gewöhnunsbedürftig, ehrlich gesagt. Die Farbe der Buttons etc. sollte auch nochmal überdacht werden. PS: Der Bilderzoom ist defekt.[/QUOTE]
Der Shop wurde migriert und sollte dem alten möglichst ähnlich sehen, und der Grafiker war mit den Standardbuttons so zufrieden. Meins wärs auch net aber die Kunden findens gut.
Kann mir jemand schnell nen Tipp geben wie ich aus Smarty an den Wert der Session Id komme…
BTW ist der Session Tracking Code im Shop wohl auch buggy - in den “Artikel pro Seite” und Sortierlinks kommt der gesamte Query-String doppelt vor (ist auch im Demo-Shop so, also nix kaputtgeflickt von mir)
Elegant:
Kompletten Original OXID Kategoriebaum mittels serialize cachen ggf. sind zus. Methoden __serialize() und __unserialize() notwendig um PHP-Core-Classen zu deaktivieren bzw. erzeugen.
Wenn dies funktioniert, dann ist das ganze halbwegs updatesicher und verhindert weitere Spiegeleffekte. So sollten die URLs wieder normal berechnet werden.
Ist aber langsamer als statische links, sollte aber trotzdem erheblich schneller als orig. Oxid sein.