Langsame Suchfunktion in xt:commerce 3

Tags: Allgemein | Debian (Linux) | MySQL | MySQL-Server | Webserver | xt:Commerce Kommentieren

Ein Kunde hatte das Problem, dass der auf unserem Server installierte xt:commerce 3 teilweise so hohen Datenbank-Load verursachte, dass der MySQL-Server abrauchte und somit den ganzen Server kurzzeitig in einer Nicht-Erreichbarkeit stürzte. Zwar war schon länger ein Update auf eine neue xt:commerce-Version geplant, jedoch befand sich der neue Shop noch in der Entwicklung und es musste kurzfristig eine Lösung erarbeitet werden, da die Ausfälle sich häuften (teilweise bis zu 3x am Tag).

Relativ schnell entpuppte sich die Suchfunktion des xt:commerce als ausschlaggebend, welche bei meinen Tests bei einer Volltextsuche meist zwischen 40 und 50 Sekunden benötigte, dabei den MySQL-Server komplett belastet – nun stelle man sich dies am Tages-Hoch mit hunderten Besuchern vor.

Mit den folgenden Umstellungen in der MySQL-Datenbank lässt sich die Suche durch einfaches Setzen von Indizes stark beschleunigen:

Tabelle „products_description„:

  • products_id
  • language_id
  • products_name
  • products_description (FULLTEXT)
  • products_short_description (FULLTEXT)
  • products_keywords

Tabelle „products_options„:

  • language_id
  • products_options_name

Tabelle „products_attributes„:

  • products_id
  • options_id

Tabelle „products_options_values„:

  • language_id
  • products_options_values_name

Tabelle „specials„:

  • products_id

Wichtig ist, dass die neuen Indexes eine möglichst hohe Kardinalität besitzen (also viele verschiedene Werte), damit eine Performancesteigerung erreicht werden kann.

Quellen

  • http://forums.xt-commerce.com/topic/60364-suchfunktion-sehr-langsam-sessions/
  • http://thomas.eses.name/mysql-indexe-richtig-setzen/

Große MySQL-Datenbanken beschleunigen

Tags: MySQL-Server | Webserver Kommentieren

In einem aktuen Fall war eine Datenbank mit ca. 60.000 Einträgen und vielen Spaltendaten bei der Abfrage simpler gefilterter Daten mit einem Limit von 0, 10 langsam und es hieß diese zu optimieren. Neben der Überprüfung der Abfragen über

EXPLAN SELECT * FROM *

in welcher dann ersichtlich ist, welche Keys hinzugezogen werden (diese sind oft ausschlaggebend für die Geschwindigkeit der Abfrage), sollte man sich ebenfalls einmal den Query-Cache des Servers ansehen.
Hierfür gibt es (oder auch noch nicht, dann hinzufügen) eine Abfrage in der my.cnf namens query_cache_limit, welche oftmals auf 0 steht. Damit ist der Query Cache deaktiviert und es werden keine Abfragen gecached. Das Caching der Abfragen speichert diese zwischen und führt diese nicht jedes Mal erneut aus (sofern sich die Tabelle nicht geändert hat). Das ist auf jeden Fall ratsam, wenn eine Datenbank nicht ständig geändert wird. Man stelle diesen Wert einfach mal auf 8M o.Ä. und beobachte in phpMyAdmin die Statusvariablen unter „Abfragen Cache“. Dort erkennt man die Auslastung des aktuellen Cache, wie viele Abfragen aufgenommen und insbesondere wie viele herausgeschmissen wurden (weil der Cache zu klein ist).
In unserem Fall haben wir einen Geschwindigkeitsschub von 1127ms (also über eine Sekunde) erreichen können. Gebe zu: Der Server ist eine kleine Krücke. Aber die Resultate überzeugen.

TOP