Im ersten und zweiten Teil der Reihe „Magento Datenbank Optimierung“ haben wir uns die Log-Funktionen genauer angesehen. Dieses Mal wollen wir die Datenbank von allen unnötigen Einträgen befreien.

Als direkte Auswirkung der Optimierung sehen wir mehr freien Speicherplatz auf der Festplatte und einen reduzierten Bedarf an Arbeitsspeicher.

Das Problem der großen Tabellen

Eine optimale MySQL-Konfiguration sieht vor möglichst viele Abfragen aus dem sehr schnellen Arbeitsspeicher zu bearbeiten. Große Tabellen verhindern dies und zwingen den MySQL-Server temporäre Tabellen auf der vergleichsweisem „langsamen“ Festplatte abzulegen.

Besonders gut bemerkbar macht sich dieser Performanceverlust bei der core_session Tabelle wenn diese, aufgrund vieler Besucher und / oder falsch eingestellter Session Lebensdauer, sehr groß geworden ist. Die Tabelle wird bei jedem Seitenaufruf nach alten Sessions gescannt, kann der Server diese nicht aus dem Arbeitsspeicher bedienen muss auf die „langsame“ Festplatte zurückgegriffen werden. Die Abfragedauer steigt dadurch von wenigen Millisekunden auf mehrere Sekunden was die Auslieferung der Website ebenfalls um diese Zeit verzögert. – Die Seitenladezeit des Magento Shops steigt (meistens) ohne erkennbare Anzeichen wie steigende Besucherzahlen oder CPU-Auslastung immens an.

Die Leerung der Session-Tabelle ist im Query nicht berücksichtigt da dies die Warenkörbe der Besucher leeren würde, dennoch empfehlen wir die Tabelle ab einer Größe von 50 – 100 MB zu leeren.

Unnötigen Ballast entfernen

Backup nicht vergessen! 🙂

Die folgenden Tabellen können und sollten regelmäßig geleert (nicht gelöscht!!!) werden damit die Performance Eures Magento Shops nicht negativ beeinträchtig wird: aw_core_logger, catalog_compare_item, catalogindex_aggregation, catalogindex_aggregation_tag, catalogindex_aggregation_to_tag, dataflow_batch_export, dataflow_batch_import, index_event, log_customer, log_quote, log_summary, log_summary_type, log_url, log_url_info, log_visitor, log_visitor_info, log_visitor_online, report_event, report_viewed_product_index, report_compared_product_index’.

Markiert dazu in phpMyAdmin die o.g. Tabellen und wählt anschließend unten im Dropdown den Befehl „Leeren“ aus.

Alternativ könnt ihr folgendes Query direkt auf der MySQL-CLI oder mit Hilfe von phpMyAdmin über den Reiter „SQL“ abfeuern. – Achtet unbedingt auf die richtige Datenbank Auswahl und die korrekten Tabellennamen im SQL-Query!

TRUNCATE 'aw_core_logger';
TRUNCATE 'catalog_compare_item';
TRUNCATE 'catalogindex_aggregation';
TRUNCATE 'catalogindex_aggregation_tag';
TRUNCATE 'catalogindex_aggregation_to_tag';
TRUNCATE 'dataflow_batch_export';
TRUNCATE 'dataflow_batch_import';
TRUNCATE 'index_event';
TRUNCATE 'log_customer';
TRUNCATE 'log_quote';
TRUNCATE 'log_summary';
TRUNCATE 'log_summary_type';
TRUNCATE 'log_url';
TRUNCATE 'log_url_info';
TRUNCATE 'log_visitor';
TRUNCATE 'log_visitor_info';
TRUNCATE 'log_visitor_online';
TRUNCATE 'report_event';
TRUNCATE 'report_viewed_product_index';
TRUNCATE 'report_compared_product_index';

Die SQL-Befehle entfernen nicht mehr benötigte Daten aus den Tabellen und sorgen somit für eine rasante Ladezeit. Andere Prozesse, wie die Erstellung eines Backups, werden durch die kleinere Datenbank ebenfalls positiv beeinflusst, so verbrauchen die meisten Vorgänge wesentlich weniger Zeit und Ressourcen (Stichwort: Timeout). 🙂

Nachdem wir in der letzten Woche (Magento Datenbank Optimierung – Teil 1) die Grundlagen für einen schnellen Magento-Shop geschaffen haben zeigen wir Euch heute weitere Möglichkeiten der Optimierung.

In einem aktuellen Projekt (ca. 50.000 Besuchern, 700.000 Seitenaufrufen und knapp 1000 Checkouts pro Tag) konnten wir durch Deaktivierung der Log-Funktionen 1 – 1,5 CPU-Kerne auf dem Datenbankserver einsparen. 

Die Änderungen aus Teil 1 sorgen für eine aufgeräumte Datenbank, allerdings loggt Magento nach wie vor jeden Zugriff in den entsprechenden Tabellen und löscht diese nach einigen Tagen wieder. Beide Vorgänge verbrauchen CPU-Ressourcen die wir sinnvoller einsetzen können, daher deaktivieren wir die Log-Funktionen heute komplett.

Deaktivierung über das Backend – Lösung mit Hindernis

Magento bietet Out-of-the-Box einige Möglichkeiten die Log-Funktionen zu deaktivieren. Am einfachsten ist es das Magento Backend zu benutzen:

Hier setzt Ihr Mage_Log auf Deaktivieren.

Die Deaktivierung über das Backend hat einen entscheidenden Nachteil: Es werden alle internen Log-Funktionen deaktiviert, somit funktionieren die Entwickler- und Extension-Logs auch nicht mehr.

MySQL Storage Engine BLACKHOLE – Das schwarze Datenloch!

Technisch etwas anspruchsvoller aber eleganter ist die Änderung der MySQL Storage Engine der Log-Tabellen auf BLACKHOLE. BLACKHOLE ist wie der Name schon sagt ein schwarzes Loch, allerdings nur in digitaler Form und wird daher „nur“ Euren Daten gefährlich.

ALTER TABLE log_url ENGINE = BLACKHOLE;
ALTER TABLE log_url_info ENGINE = BLACKHOLE;
ALTER TABLE log_visitor ENGINE = BLACKHOLE;
ALTER TABLE log_visitor_info ENGINE = BLACKHOLE;

Das oben gezeigte Query müsst Ihr direkt auf der MySQL-CLI oder mit Hilfe von phpMyAdmin über den Reiter „SQL“ abfeuern. – Achtet unbedingt auf die richtige Datenbank Auswahl und die korrekten Tabellennamen im SQL-Query!!!

Sobald das SQL-Query ausgeführt wurde sind die Log-Tabellen leer und sämtliche neu zu schreibende Log-Daten werden sofort verworfen.

Die BLACKHOLE-Lösung hat einen entscheidenden Vorteil gegenüber der Backend-Lösung da aus Magento-Sicht nach wie vor alle Log-Funktionen aktiv sind. Die Entwickler- und Extension-Logs könnt Ihr nutzen, an die Log-Tabellen gesendete Daten werden allerdings nicht verarbeitet und verschwinden direkt in unserem schwarzen Loch. Ganz ohne die CPU oder unsere Speichermedien zu belasten! 😀

In der nächsten Folge (Magento Datenbank Optimierung – Teil 3) zeigen wir Euch zwei kleine aber sehr wirkungsvolle SQL-Querys zur Optimierung der Magento Datenbank.

Immer wieder werden wir, in Beratungsgesprächen zu unserem Magento Hosting und der täglichen Arbeit im Support, nach der optimalen Konfiguration eines Magento-Shops gefragt.

Unser Wissen möchten wir gerne weitergeben, deshalb findet Ihr ab heute in der Kategorieliste rechts den Punkt Performance. In unregelmäßigen Abständen werden wir hier kurze Beiträge mit leistungssteigernden Maßnahmen vorstellen.

Starten werden wir heute mit einem der häufigsten Gründe für einen langsamen Magento-Shop und Backup-Probleme, die immer größer werdenden Log-Tabellen.

Nach der Installation loggt Magento jeden Zugriff auf eine beliebige Seite in der Datenbank. Die Daten können später dazu genutzt werden Statistiken oder andere Auswertungen zu erstellen, in der Regel werden diese Daten allerdings nie benötigt da externe Dienste wie Google Analytics zum Einsatz kommen.

Der Cronjob – ohne ihn geht nichts

Grundlegend für die fehlerfreie Funktion von Magento ist die Einrichtung des Cronjobs. Die Aufgabe eines Cronjobs ist es in regelmäßigen Abständen bestimmte Aufgaben zu erledigen, welche das im Detail sind könnt Ihr im Magento Wiki nachsehen. Neben den Standardaufgaben wie Newsletterversand, Index- und Sitemaperstellung führt das Script auch diverse Wartungsarbeiten aus. Wie Ihr einen Cronjob einrichtet erfahrt Ihr im Kundencenter.

Auf die richtigen Einstellungen kommt es an!

Nachdem der Cronjob eingerichtet wurde müssen wir noch einige Einstellungen im Magento Backend vornehmen. Das Menü zur Konfiguration der Log-Bereinigung findet Ihr unter:

Da der Vorgang je nach Datenmenge sehr viele Ressourcen beanspruchen kann sollte die Bereinigung in der Nacht erfolgen. Die Anzahl der Tage kann beliebig konfiguriert werden. – Je kürzer desto besser! 🙂

Einstellungen der Log-Bereinigung in Magento

Sobald der Cronjob eingerichtet und die Einstellungen vorgenommen wurden ist alles korrekt konfiguriert, in der folgenden Nacht startet der Job pünktlich seine Arbeit und räumt Eure Magento Datenbank gründlich auf.

In der nächsten Folge (Magento Datenbank Optimierung – Teil 2) erklären wir die komplette Deaktivierung der Log-Funktion und zeigen euch wie ihr die Datenbank weiter aufräumen könnt.