MySQLnd – MySQL Query Cache

Die Welt ist komisch, gerade in der Webentwicklung. Dort bewegt man sich zwischen Unwissenheit und Holzhammer-Problematiken. Hinzu kommt, dass bei Optimierungen oft an der verkehrten Stelle geschraubt wird. Wieso das so ist? Eigentlich bezahlt einem das keiner. Entweder man arbeitet direkt von vorne herein sauber, oder man zahlt eventuelle Optimierungs-Arbeiten – aufgrund einer langsamen Seite – selbst.

Screenshot von MySQLnd auf MySQL Forge

Ein Großteil der hier gemachten Arbeiten wäre gar nicht notwendig, wenn man von vorne herein Datenbanken normalisiert, und entsprechende Indexe einsetzt.  Wenn man dann in Probleme rennt wird lustigerweise genau an einer Stelle geschraubt: PHP selbst. Es ist mir rätselhaft wieso dann niemand auf die Idee kommt, dass auch MySQL schuld sein könnte. Wenn ich ein neues Projekt übernehme ist es in der Regel so, dass die my.cnf den Default-Einstellungen entspricht. Entsprechend wird mit Caching direkt in PHP gearbeitet, oder APC (oder ähnliches) eingesetzt.

Die Welt könnte einfacher sein, wenn man auch mal nach MySQL guckt, und manchmal macht es auch Sinn MySQL selbst einen Query Cache zu verpassen. Ein nettes Tutorial zur Nutzung gibt es hier. Dies sollte meines Erachtens aber die letzte Lösung sein, denn BEVOR ich ein Caching in MySQL oder PHP verwende, gibt es einige (zumeist funktionierende) Möglichkeiten um eine Seite zu beschleunigen – womit wir weder beim Holzhammer wären, denn scheinbar setzt man eher auf die Fire & Forget Methode – und der Kunde muss sich fragen, ob er da nicht eine Mitschuld trägt.

Ähnliche Beiträge

DBKiss – eine weitere Alternative zu phpMyAdmin Meine Meinung bzgl. phpMyAdmin dürfte inzwischen hinlänglich bekannt sein, ich für meinen Teil benutze inzwischen fast nur noch Adminer für das Frank ...
DBeaver – freier Datenbank-Manager Datenbanken sind in der Regel groß und mächtig, und selten möchte man diese über die Kommandozeile verwalten. Die wohl gleichsam schlimmste und am wei...
SQLite mit Lita administrieren Zugegebenermaßen ist SQLite nicht weit verbreitet – denkt man zumindest ;) 98% der Webworker nutzen MySQL und rücken von diesem Standard keinen Zentim...
MySQL – Optimale Größe für Feldtypen Was ich wirklich und mit aller Leidenschaft hasse, sind Programmierer die im Fire&Forget-Stil Größen von Feldtypen in MySQL setzen - und dann auch...

Eine Antwort auf „MySQLnd – MySQL Query Cache“

  1. Danke für die Erwähnung!

    Die Zwischenspeicherung von Daten ist eine Standardmethode zur Beschleunigung von Webseiten. Selbstverständlich gilt es bestehende Komponenten (z.B. Datenbank) optimal auszunutzen bevor eine neue Komponente (z.B. Cache) in die Architektur eingefügt wird.

    Sollte ein Anwender über die Möglichkeit verfügen, die Datenbank zu konfigurieren, dann bietet sich die Nutzung des in MySQL eingebauten Query Caches an.

    Davon abzuraten ist, wenn die Verbindung zwischen Datenbank und Klient (PHP) langsam ist. Die Langsamkeit kann durch Latenz oder geringe Bandbreite erzeugt werden. Klassisches Beispiel: Datenbank in den USA, Webserver mit PHP in Deutschland – mit etwas Pech ist die Verbindung der Flaschenhals, d.h. die Übertragung der Ergebnisse einer Datenbankanfrage dauert länger als ihre Erzeugung. Sollte dies der Fall sein, ist eine Optimierung der Berechnung der Anfrageergebnisse verlorene Liebesmühe. Stattdessen ist es besser einen lokalen Cache einzusetzen. Strukturell gesehen ist das nichts anderes als ein lokaler Proxy für HTTP-Inhalte, wie – im Extremfall – ein Browsercache.

    Der Vorteil von PECL/mysqlnd_qc ist die Einfachheit der Benutzung. Das Plugin erweitert den Datenbanktreiber und wird per SQL-Hints kontrolliert. Es sind nur minimale Applikationsänderungen (SQL-Hints einfügen oder Callback installieren) notwendig. Das ist super für „ich habe da ein Problem, kann MySQL nicht konfigurieren und will mal schnell ausprobieren ob es was bringt alle oder die meisten SQL-Anfragen zu cachen“. Alternativ auch „ich brauche wirklich nur mal einen Cache für ein paar SQL-Anfragen“.

    Der Nachteil ist die Einfachheit von PECL/mysqlnd_qc. Die Granularität ist eine SQL-Anfrage. Wird eine Webanwendung vom ersten Tag an auf Caching vorbereitet werden sich wahrscheinlich fertig berechnete Aggregate finden, deren Zwischenspeicherung mehr Ersparnis verspricht.

    Damit ich nicht falsch verstanden werde: ich freue mich natürlich über jeden der PECL/mysqlnd_qc ausprobiert und ich hätte es nicht entwickelt, wenn ich nicht von der Nützlichkeit überzeugt wäre.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.