Performance Optimierung für xt:Commerce / commerce:SEO

    • Offizieller Beitrag

    Hier nun mal ein Ansatz, einen xt:Commerce oder commerce:SEO mit mehr als 10.000 Artikeln auf die Sprünge zu helfen (bei weniger hilft das aber auch), wenn man nicht gerade eine eigene und gut dimensionierte Power-Maschine sein Eigen nennt.

    Was ist die Idee:
    Der integrierte Cache ist ja mitunter nicht 100% so, wie man es gern haben möchte und er erzeugt auch eine riesen Menge an Dateien im cache Ordner. Alle Produkte einzeln zu cachen macht eigentlich auch nicht viel Sinn, da ja oft Änderungen an diesen vorgenommen werden. Was sich hingegen kaum ändert, sind die Kategorien, Bestseller und die Content-Verlinkungen. Man mag es kaum glauben, aber die Bestsellers-Box bremst bei so einem Shop erheblich die Performance aus, da hier doch sehr komplexe Datenbank Abfragen gemacht werden. Man kann diese zwar generell abschalten, aber viele wollen eben genau das nicht.
    Wie kann mal also den Cache trotzdem sinnvoll nutzen?

    Der Lösungsansatz:
    Man cached nur einen Teil des Shops und nur die Boxen, die Sinn machen.

    Die Erfahrung:
    Wir haben bereits bei mehreren Kunden diesen Ansatz umgesetzt und erhebliche Performance-Verbesserungen festgestellt.

    Vorbereitung: BACKUP der Dateien!!!

    Die Umsetzung:
    Schritt 1:
    Im Template Ordner gehen wir als 1. in die Datei:

    /templates/TEMPLATENAME/source/boxes.php

    und fügen dort vor der Zeile:

    PHP
    include(DIR_WS_BOXES . 'categories.php');

    folgendes hinzu:

    PHP
    define('FORCE_CACHE',true);

    Damit wird der Cache generell erst mal eingeschaltet für die Boxen. Nun müssen wir den einzelnen Boxen aber noch mitteilen, das diese cachen sollen.

    Schritt 2:
    Box Bestsellers:
    /templates/TEMPLATENAME/source/boxes/best_sellers.php

    Folgende Zeile suchen:

    PHP
    if (!CacheCheck()) {

    Und ERSETZEN mit:

    PHP
    if (!CacheCheck() || !FORCE_CACHE) {

    Schritt 3:
    Box Categories:
    /templates/TEMPLATENAME/source/boxes/categories.php

    Folgende Zeile suchen:

    PHP
    if (!CacheCheck()) {

    Und ERSETZEN mit:
    if (!CacheCheck() || !FORCE_CACHE) {
    [/code]

    Schritt 4:
    Box Informaton:
    /templates/TEMPLATENAME/source/boxes/information.php

    Folgende Zeile suchen:

    PHP
    if (!CacheCheck()) {



    Und ERSETZEN mit:

    PHP
    if (!CacheCheck() || !FORCE_CACHE) {

    Schritt 5:
    Box Content:
    /templates/TEMPLATENAME/source/boxes/content.php

    Folgende Zeile suchen:

    PHP
    if (!CacheCheck()) {



    Und ERSETZEN mit:

    PHP
    if (!CacheCheck() || !FORCE_CACHE) {

    So und jetzt mal testen. Hier sollte man nun eine deutliche Verbesserung der Performance feststellen.

    Zusammenfassung:
    Was haben wir also getan? Wir haben den Cache generell für die Boxen eingeschaltet, aber nur den Boxen Bestsellers, Categories, Information und Content den Cache auch wirklich verpasst. Die anderen Boxen machen wenig Sinn, da diese doch sehr dynamisch sind und bleiben sollten. Kategorien, Content und die Bestsellers ändern sich hingegen kaum. Worauf greien wir dabei zurück? Hier wird auf die Shopeinstellung für den Cache zurück gegriffen, aber nur die Lebenszeit des Cache (Standard = 3600 Sekunden). Das muss man an der Stelle im Hinterkopf behalten, da bei Änderungen in den Boxen erst nach 3600 Sekunden die entsprechende Box neu geladen wird, sofern es Änderungen gibt.

    Hinweis: Wir haben Die Idee übernommen und weiter ausgebaut.

    <p>Wir geben nur Anregungen und Hilfestellung auf Basis unserer Erfahrung, keine Rechtshilfe!<br>\m/('_')\m/</p>

    Einmal editiert, zuletzt von siekiera (3. Dezember 2010 um 11:17)

    • Offizieller Beitrag

    Bedank :rolleyes:
    Ja, so haben wir das schon bei einigen Kunden umgesetzt und funzt prima, vor allem bei großen Datenmengen bringt das enorm viel.
    Aber, ich habe noch eine SQL Optimierung als Anhand hier, die bringt auch noch einmal einen Turbo! Habe gerade einen Shop mit 700.000 Produkten optimiert unter anderem damit. VORHER aber Backup vom Shop, Einsatz auf eigenes Risiko! Habe es mehrfach schon eingesetzt und geht.

  • Klingt ja nicht schlecht,
    mein Shop hängt sich mit kurz über 5000 Artikeln bei directurl v3 auf.
    Server liegt bei 1un1, hompage perfect, bin mir nun nicht sicher ob es am server oder an shop liegt
    es sollen ca. 100 000 Artikel rein, server wechseln oder Datenbank optimieren?

    Bitte um Hilfe

  • Das Problem ist die Menge an Produkten und DirectURL v3.

    Bei einem Seitenaufruf muss der Shop durch die DB rammeln und aus den 5000 Artikel in die Namen miteinander vergleichen. Das schlaucht enorm.
    Evt. könnte der "admin" mal ein Indizies-System entwickeln um das suchen und vergleichen zu beschleunigen.

    • Offizieller Beitrag

    Bei 100.000 Artikeln kommst Du mit einen nomalen Webpaket nicht mehr hin. Da musst Du schon mal einen einen eigenen Server denken. Eine DB optimierung zusätzlich sollte auch in Erwägung gezogen werden. Der Shop basiert auf xt:Commerce! und einige Altlasten, besonders in Richtung Performance sind auch noch in der 1.1.1 drin. Bei dieser Menge sollte auf jeden Fall ein Profi noch mal ran.
    P.S.: Das was hier beschrieben ist, funktioniert prinzipiell auch gut, allerdings kann ich nur einen Vergleich mit DirectURL mit ca. 15.000 Artikeln ziehen, das habe ich schon gemacht. Kunde hat eigenen Server.

    • Offizieller Beitrag

    Sieht recht schmal aus. Besser, Dual Core mit mindestens 4-8GB RAM, je nach Besucheranzahl. Generell können wir so was machen, aber NICHT vor März / April! Wir arbeiten mit Hochdruck an der V2.

  • Bedank :rolleyes:
    Ja, so haben wir das schon bei einigen Kunden umgesetzt und funzt prima, vor allem bei großen Datenmengen bringt das enorm viel.
    Aber, ich habe noch eine SQL Optimierung als Anhand hier, die bringt auch noch einmal einen Turbo! Habe gerade einen Shop mit 700.000 Produkten optimiert unter anderem damit. VORHER aber Backup vom Shop, Einsatz auf eigenes Risiko! Habe es mehrfach schon eingesetzt und geht.



    Was genau macht diese SQL Datei? Bleiben meine alten Daten erhalten? Würde das gern vorher wissen bevor ich die in importiere

  • Bedank :rolleyes:
    Ja, so haben wir das schon bei einigen Kunden umgesetzt und funzt prima, vor allem bei großen Datenmengen bringt das enorm viel.
    Aber, ich habe noch eine SQL Optimierung als Anhand hier, die bringt auch noch einmal einen Turbo! Habe gerade einen Shop mit 700.000 Produkten optimiert unter anderem damit. VORHER aber Backup vom Shop, Einsatz auf eigenes Risiko! Habe es mehrfach schon eingesetzt und geht.

    Hi,
    werden die zusätzlichen Index-Dateien in "jeder normalen Lebenslage", sprich: auch bei allen Aktualisierungen der Datenbank (Löschen, einfügen pp) "automatisch&fehlerfrei" immer mit auf den neuesten Stand gebracht oder muss man dazu in die Quelltexte eingreifen??? Wann ist eine Re-indizierung der Datenbank sinnvoll? Gibt es bei mysql eine automatische Prüfung auf Indexfehler?

    Gruß
    Bernd E.

    • Offizieller Beitrag

    Die Indexe werden in der DB verwaltet. Nun, da musst Du dich schon auf die MySQL verlassen. Eine regelmäßige Optimierung (am besten per Hand) ist sicher ratsam. Automatisiert habe ich schon mal schlechte Erfahrung gemacht.

  • Hi,
    werden die zusätzlichen Index-Dateien in "jeder normalen Lebenslage", sprich: auch bei allen Aktualisierungen der Datenbank (Löschen, einfügen pp) "automatisch&fehlerfrei" immer mit auf den neuesten Stand gebracht oder muss man dazu in die Quelltexte eingreifen??? Wann ist eine Re-indizierung der Datenbank sinnvoll? Gibt es bei mysql eine automatische Prüfung auf Indexfehler?

    Gruß
    Bernd E.

    Wenn ich Dich richtig verstehen willst Du wissen ob Die Indizierungen in der Datenbank(Tabellen) erhalten bleiben, wenn Du neue Artikel hochläds bzw. nach Update der DB?
    Wenn dem so ist dann: ja, die Indizierungen bleiben solange erhalten bis Du sie per Hand oder mit SQL Befehl änderst.
    Normale Produkte-Updates haben keine Auswirkung auf die Indizierungen, da die Tabelle meines Wissens nicht gelöscht und wieder neu erstellt wird bei jedem Update.

  • Danke für die Rückmeldungen,

    ich habe mich vor Urzeiten nur mit Clipper-Datenbanken herumgeschlagen und sehe, dass mir betr. MySql ein paar Grundlagen fehlen, da zwischen den beiden Systemen wohl doch Welten liegen.
    Um einwenig aufzuholen, habe ich mir jetzt entspr. Literatur besorgt: PHP 5.3 & MySQL 5.1: Grundlagen, Programmiertechniken, Beispiele

    Gruß
    Bernd E.

  • 1. In wie weit sind die performance optimierungen, welche im ersten post genannt werden, in der V2 umgesetzt?



    Alle Tricks die wir kennen sind grundsätzlich nach der Installation verfügbar. Auch die Indizies sind dann schon gesetzt. Einige User können mit sowas jedoch nichts anfangen und bauen sogar den Cache wieder aus. Naja, jeder weiß was er tut.

    Hardware-Technisch hat der Admin schon mal was geschrieben, danach kannste suchen. Glaube was mit Dual Core und min. 4GB Ram, oder so.

  • Bei der advanced_search in v1.1.1 wirkt das Entfernen von DISTINCT Wunder in der sql-search-query in der SQL-ausführung bei sehr hoher Produktanzahl. Man drücke mal in einem Shop ohne Suchstringeingabe auf den Suchen-Button, was theoretisch alle vorh. Produkte als Ergebnis liefert.
    (bei Worstcase-szenario etwa 50 Sek auf unter 1Sek.)
    Bei uns auf den ersten Blick ohne Nebenwirkung.

    Ist jetzt nur die Frage, warum das DISTINCT dort überhaupt mal reingesetzt wurde...