Magento Datenbank Optimierung – Teil 3

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.

cpanel-phpmyadmin-truncate

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). :)


Magento Datenbank Optimierung – Teil 2

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:

System -> Konfiguration -> Erweitert -> Modulausgaben

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! :D

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.


Magento Datenbank Optimierung – Teil 1

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:

System > Konfiguration > Erweitert > System > Log Bereinigung

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! :)

Magento Log Bereinigung

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.


Kritische Magento Sicherheitslücke – Patch erforderlich!

Am 11.12.2013 wurde im Magento Core eine schwerwiegende Sicherheitslücke entdeckt. Die Lücke erlaubt es einem Angreifer Zugriff auf die gesamte Magento Instanz inkl. Datenbank zu erhalten.

Betroffen sind alle Magento Versionen von 1.4.0.0 bis 1.7.0.2! – Die letzte aktuelle Version 1.8.0.0 ist nicht betroffen.

Wir raten daher allen Kunden schnellstmöglich den bereitgestellten Patch, passend zur eingesetzen Magento-Version, einzuspielen!

Einspielen des Magento-Patches per SSH:

  1. Download des passenden Patches von Magentocommerce.com (ganz unten)
  2. Upload des Patches in den Ordner public_html
  3. sh PATCH-DATEINAME.sh
  4. Alle Caches leeren um die Änderungen zu übernehmen: System > Cache Management

Einspielen des Patches ohne SSH:

  1. Download des passenden Patches von Magentocommerce.com (ganz unten)
  2. Öffnen des Patches im Texteditor
  3. Öffnen der Datei app/code/core/Mage/Cms/Helper/Wysiwyg/Images.php auf dem Server
  4. Einspielen des Patches
    1. Nach “public function getCurrentPath()” (ohne “”) in der Datei Images.php auf dem Server suchen
    2. Manuelles Anwenden des Patches: Zeilen im Patch mit einem Minus (-) werden entfernt, Zeilen mit einem Plus (+) ergänzt
  5. Alle Caches leeren um die Änderungen zu übernehmen: System > Cache Management

Das Entwicklerteam empfiehlt die Änderungen vorher in einer Testumgebung zu prüfen!

rack::SPEED Kunden können jederzeit die Unterstützung unseres Support-Teams in Anspruch nehmen.


24-Kerne, 96 GB DDR3 RAM, ultraschnelle SSDs…

… die neue Grundlage für hochperformantes SSD-Webhosting!

Schnell ist uns nicht schnell genug, daher haben wir unsere Server von Grund auf neu geplant und konfiguriert. Das Herzstück bilden 2x XEON E5-CPUs (24-Kerne mit HT), 96 GB DDR3 RAM mit ECC-Fehlerkorrektur, ultraschnelle SSD-Laufwerke, Intel Hardware-RAID 1 und 1000 MBit Netzwerk-Uplink.

Neben der beachtlichen Leistungssteierung haben wir versucht eure Anregungen umzusetzen. Das Resultat ist eine großartige Hosting-Plattform mit zahlreichen Zusatz-Features!

Jede Website hat irgendwann Saison, daher haben wir uns etwas ganz besonderes einfallen lassen: Der +100% Saison-Turbo! – Bis zu 3 Monate +100% Leistung für deine Website, je nach Tarif für 1 oder 3 Monate aktivierbar. Kein Serverumzug, kein Ausfall, kein Umzugs-Stress in der heißen Phase!

Ab sofort könnt ihr zwischen den PHP Versionen 5.2, 5.3 und 5.4 per Mausklick wechseln, auch die Konfiguration der bereitgestellten PHP-Extensions ist frei konfigurierbar.

Ein Pluspunkt für Entwickler ist die Integration von mod_pagespeed, GIT und SSH-Zugang.

Abgerundet wird das Ganze durch lange Scriptlaufzeitengroßzügig bemessener PHP-Speicher, 100% Ökostrom aus Wasserkraft und eine aktuelle MySQL 5.5 Instanz.

Notiert euch bereits jetzt den Promo-Code RELAUNCH2013 für den kommenden Montag! :)


Zend Framework Sicherheitslücke – Patch erforderlich!

Soeben wurde von Varien in einem Blogbeitrag bekannt gegeben, dass im Zend Framework (XMLRPC-Funktion) welches Magento zu Grunde liegt eine gravierende Sicherheitslücke entdeckt wurde.

Betroffen sind alle Magento Versionen von 1.4.0.0 bis 1.7.0.1! – Die letzte aktuelle Version 1.7.0.2 ist nicht betroffen.

In unserem Forum wurde soeben eine detailierte Schritt-für-Schritt Anleitung zur Beseitigung der Sicherheitslücke hinterlegt.


Sicherheitsupdate: Magento 1.7.0.2 erschienen!

Die aktuelle Version 1.7.0.2 ist ein reines Sicherheitsrelease und behebt die folgenden Fehler:

Laut Release-Notes wurden zahlreiche Bugs behoben! – Die Änderungen stehen wie gewohnt auch als Diff-File zum Download bereit!

ACHTUNG: Wie immer sollte vor dem Update ein Backup erstellt und das Compiler-Modul deaktiviert werden!


Update: Magento 1.7.0 erschienen!

Die Magento Community Version CE 1.7.0.0 bringt einige Neuerungen und Features mit sich, dazu zählen u.a.:

  • Verbesserte Layered Navigation (verschiedene Preisstufen nach Größe)
  • Captchas hinzugefügt
  • Basispreise nach Kundengruppe
  • Automatische Generierung von Coupon-Codes
  • Neue Backup und Restore-Funktionen
  • Prüfung der UstID
  • DHL Europa
  • REST API
  • Neues Mobile Theme

Laut Release-Notes wurden zahlreiche Bugs behoben! – Die Änderungen stehen wie gewohnt auch als Diff-File zum Download bereit!

ACHTUNG: Wie immer sollte vor dem Update ein Backup erstellt und das Compiler-Modul deaktiviert werden!


Update: Magento 1.6.0 erschienen!

Das Magento Update der Version 1.6 wurde gestern Abend veröffentlicht. Neben den üblichen Bugfixes ist dieses Mal ein lang erwartetes Features hinzugekommen, der “persistente Warenkorb“!

Mit Hilfe des persistenten Warenkorbs können Kunden unabhängig von der aktuellen Browsersession auf die im Warenkorb abgelegten Produkte zugreifen, das lästige Neubefüllen nachdem der Browser geschlossen wurde entfällt damit!

Laut Release-Notes wurden über 300 Bugs behoben! – Die Änderungen stehen wie gewohnt auch als Diff-File zum Download bereit!

ACHTUNG: Wie immer sollte vor dem Update ein Backup erstellt und das Compiler-Modul deaktiviert werden!


Sicherheits-Update: Magento 1.5.0.1 schließt gravierende Sicherheitslücke!

Aufgrund der gravierenden Sicherheitslücke in Magento Version 1.5.0.0 wurde heute ein weiteres Update herausgebracht. Wir stufen das Update als kritisch ein und empfehlen jedem Nutzer der Version 1.5.0.0 das Update kurzfristig einzuspielen!

Das Update entfernt die fehlerhafte Implementierung des neuen Datenbank-Storage und schließt so ersteinmal das entstandene Leck. Man will nun die fehlerhafte Funktion prüfen und in einem späteren Release wieder einbauen, dennoch fragt man sich wie ein so grober Fehler passieren konnte…

Laut Release-Notes wurden weitere Bugs behoben! – Die Änderungen stehen wie gewohnt auch als Diff-File zum Download bereit!

ACHTUNG: Wie immer sollte vor dem Update ein Backup erstellt und das Compiler-Modul deaktiviert werden!