Was ist denn Memcache?

Memcache ist ein Dienst, der es erlaubt, Daten im Arbeitsspeicher vorzuhalten. Daneben erlaubt er es auch noch, dies über mehrere Server zu verteilen, also ein richtiges Speicher-Netzwerk aufzubauen. Und Arbeitsspeicher ist eine der schnellsten Zugriffsformen auf Daten, die wir zur Zeit haben. Memcache kann durch das Zwischenspeichern von Daten, die sonst mühsam aus anderer Stelle geholt werden müssen, das Leben leichter und angenehm schneller gestalten.

Dazu muss man sagen, dass ja Webanwendungen von Seitenaufruf zu Seitenaufruf jeweils neu initialisiert werden müssen. Als Benutzer in einer Sitzung (Session) ist einem das oft nicht bewusst, aber es kostet den Server bei jedem Klick eine entsprechende Zeit, die Session zu restaurieren und die Daten wieder so herzustellen, damit die nächste Aktion ausgeführt werden kann. Die Sessions werden in einer Datei auf dem Server abgelegt. Das heißt also auch Festplattenaktivität pro Klick. Das ist doof. Noch dümmer, dass man nicht wirklich viel in solch eine Session legen kann und sollte. Je größer das Session-File, desto langsamer wird jeder einzelne Aufruf. Dinge also, die nicht wirklich essentiell sind, holt man also immer wieder neu aus einer Datenbank oder anderen Quellen.

Daneben gibt es noch Session-unabhängige Daten. Bei einem News-Portal also die aktuellen Beiträge zum Beispiel. Doch die sollte man nicht jedem der Millionen von Nutzern in die Session legen. Dabei sind diese ständig gefragt, was macht man also damit? Memcache ist hier die richtige Lösung. Mit Memcache lassen sich diese nutzerunabhängigen Daten genau einmal speichern, aber für jeden Nutzer in hoher Geschwindigkeit bereitstellen. Das macht richtig Spaß.

Was geht in Memcache rein?

Das Beste ist: Memcache bildet nur eine simple Zuweisung von Key-Value-Paaren ab. Unter einer Zeichenkette als Schlüssel, der maximal 250 Zeichen Länge betragen darf, werden einfache Zeichenketten als Werte hinterlegt. Die Werte dürfen maximal 1 MB Größe haben. Was man darin speichert, ist tatsächlich vollkommen egal. Man kann also gezielt eine Datenbank beschleunigen oder aber auch Template-Engines entlasten, also ganze HTML-Vorlagen ablegen, vielleicht auch schon komplett mit allen Inhalten gerendert. Ebenso lassen sich die Einträge unabhängig von deren Nutzung befüllen, zum Beispiel nachts, wenn die Last der Server geringer ist. Tagsüber stehen dann z.B. aggregierte Daten zum schnellen Abruf bereit.

Die PHP-Schnittstelle ist dazu mit einer automatischen Serialisierung implementiert. Man kann also einfach komplexere Objekte und Arrays einfach hineinwerfen – und so kommen sie auch heraus. Einzig und allein Pointer wie Dateizeiger oder auch (Datenbank-)Verbindungen sollte man nicht hineinwerfen, denn Ressourcen können im Allgemeinen nicht richtig wiederhergestellt werden. Jeder Eintrag kann dabei on-the-fly mit zlib komprimiert werden, sollte es sich um größere Datenmengen handeln, um im 1-MB-Bereich zu bleiben oder einfach aus Speichergründen. Der Dienst memcached wird außerdem mit einer Option -m für die Gesamtspeichergröße

/usr/local/bin/memcached -d -m <Anzahl der MB> -p 11211 -l 127.0.0.1 -u nobody

gestartet, sodass bei -m 2048 maximal 2 GB des Arbeitsspeichers belegt werden. Nicht zuletzt wird beim Zwischenspeichern ein Zeitlimit gesetzt, wie lange der Cache-Eintrag gültig sein soll.

Anwendung am Beispiel www.ebrosia.de

Zunächst habe ich ein Profiling unserer Startseite gemacht. Die sollte wohl sehr häufig aufgerufen werden. Insgesamt bietet allein diese Seite Anlass für über 100 Datenbank-Abfragen, wenn man alles streng nimmt. Also ist das mein erstes Optimierungsgebiet gewesen. Es gibt natürlich Abfragen, die man besser nicht zwischenspeichert, wie zum Beispiel den Warenkorb des Benutzers – der sollte immer auf die Sekunde aktuell sein. Die Zusammenfassung des Warenkorbs (x Artikel mit y Gesamtpreis) wandert also am besten in die Session: Verbraucht nicht viel Platz, ist nutzerabhängig und wird bei einer Änderung am Warenkorb neu errechnet, also eher selten.

Bei der Entscheidung, ob ganze Templates optimiert werden sollen, habe ich mich dagegen entschieden: Die Mehrzahl der Seiten bietet für eingeloggte Nutzer individualisierte Inhalte, dazu sind die Templates nicht wirklich die Zeitfresser, da reines HTML und PHP zum Einsatz kam, also keine Layout-Engine verwendet wird. Die Seiten leben eher von den kleinen Abfragen an die Datenbank. Hier und da geht es um Links zu einem Artikel, um einen Preis, einen Artikelnamen. Speziell zu Wein kamen noch das Land, ein Gebiet oder eine Rebsorte hinzu.

Wenn man einen Shop betreibt, dann sind die Produktdaten das A und O, gerade bei etwa 1000 Artikeln. In fast jeder Shop-Seite, besonders auf der Startseite, kommen mehrere, auch wechselnde Artikel vor. Jeder Artikel hat einen Namen, einen Preis, einen Rabatt und eine Lieferbarkeit. Diese Daten werden eventuell mehrfach pro Sekunde abgerufen, aber vielleicht nur einmal im Monat geändert, zum Beispiel bei einer Rabatt-Aktion. Setzt man hier ein Zeitlimit von 10-20 Minuten an, sollten also geschätzte 90% der Aufrufe mit Memcache abgefangen werden, ohne dass die Aktualität leidet. Ich habe mich für ein kurzes Zeitfenster von 10 Minuten entschieden, um im Fehlerfall flexibler zu bleiben.

Also habe ich dort angesetzt. Memcache bildete eine Art Zwischenschicht zwischen dem Shop als Gestaltung und dem Datenbank-Backend. Letztlich konnte ich so mit nur einer kleinen Memcache-Implementierung im Backend gleich sehr viele Shop-Seiten verbessern, die auf die optimierten Funktionen mit den SQL-Abfragen zugreifen. Mit der Zwischenspeicherung von Preisen, Rabatten, Namen von Artikeln und Kategorien habe ich die Startseite auf ein durchschnittliches Volumen von etwa 5 SQL-Anfragen gedrückt. Diese Anfragen gehen auf die stetige Erneuerung von Cache-Einträgen wie auch das Rotieren von Produkten in Teasern zurück. Letztlich betrug die Zeit der Auslieferung der Startseite nur noch 35-50 Millisekunden (PHP-Start bis PHP-Ende). Seiten ohne SQL-Inhalte bewegten sich gleichen Zeitrahmen. Man konnte demnach davon ausgehen, dass das Caching die Belastung des MySQL-Servers auf ein Minimum reduziert hatte.

Im zweiten Schritt ging es dann an Artikel- und Kategorie-Seiten. Diese waren schon weitgehend durch den vorigen Schritt entlastet. Es waren nur noch wenige Handgriffe zu tun, um auch hier an die gleichen Rendering-Zeiten zu gelangen. In Frieden ließ ich den individuellen Konto-Bereich der Kunden. Hier wäre auch das Optimierungspotenzial geringer. Mit dem investierten Aufwand bin ich bereits weit genug gekommen für eine erste Runde.

Rollout auf dem Webserver

Libevent installiert und memcache kurz kompiliert, schon konnte es losgehen. Der Dienst startete angenehm einfach. Das PHP-Modul ist mit einem einfach phpize, configure und make ebenso leicht aufgesetzt. Jetzt nur noch das Modul in der php.ini fest eingetragen und nach einem kurzen Neustart des Apache sagte mir ein Testskript “Ja, es ist angerichtet.”

Der Shop wurde synchronisiert, und schwupps, kamen erste Ergebnisse im Cache an. Das Gefühl eines schnelleren Arbeitens war wirklich omnipräsent, das fühlte sich gleich gut an. Nach einigen Stunden Laufzeit hatte Memcache eine Trefferquote von etwa 87% zu verzeichnen, und die Last auf dem DB-Server war damit drastisch gefallen. An die Optimierung weiterer Bereiche kann nun Schritt für Schritt herangegangen werden. Nagios zeichnet flachere Kurven, und der Admin ist zufrieden. Jetzt kann Weihnachten kommen.

Die Installation

Fangen wir mal mit der Installation an. Unter Linux gibt es in jeder Distribution die bequeme Art des Paketmanagers. Unter Windows gibts Install-Programme (bei Postgresql ab Version 8). Wer Binaries vertraut, hat so oder so ziemlich schnell die Datenbank-Umgebung installiert. Insofern gibts hier nix zu beanstanden, alles sehr einfach.

Wer selbst kompilieren will, um auf dem neuesten Stand zu sein, sollte natürlich die üblichen Verdächtigen configure und make benutzen können. Aber wer will das schon? Das lassen wir der Einfachheit halber ganz schnelle beiseite.

Aller Anfang ist schwer

Ist die Datenbank installiert, so will man diese natürlich gleich ausprobieren. Wie macht man denn das überhaupt? Am schnellsten geht das über stets mitgelieferte Kommandozeilen-Programm. Bei Postgres heißt das psql, bei MySQL einfach mysql.

postgres@lx:/$ psql
Dies ist psql 8.3.3, das interaktive PostgreSQL-Terminal.

Geben Sie ein:  \copyright für Urheberrechtsinformationen
                \h für Hilfe über SQL-Anweisungen
                \? für Hilfe über interne Anweisungen
                \g oder Semikolon, um eine Anfrage auszuführen
                \q um zu beenden

postgres=#

oder auch

lx:/home/nudge# mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 41
Server version: 5.0.51a-12 (Debian)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

Der Benutzer

Um sich erfolgreich anzumelden, braucht man einen Nutzernamen, einen Host und eventuell ein Passwort. Dies alles muss vorher in der Datenbank über die Rechtevergabe konfiguriert sein. Postgresql setzt hier ganz stark auf System-Benutzer, MySQL pflegt Nutzer über Tabellen in MySQL selbst. Beides hat Vor- und Nachteile.

Postgresql zum Beispiel ist dadurch recht robust: Man braucht kein zusätzliches Datenbank-Passwort. Und ordentliche Nutzerpflege vorausgesetzt, ist das auch das sicherste. Allerdings sind Datenbanken meist dort installiert, wo Server rauschen und viele Homepage-Hobby-Admins auf einer Maschine arbeiten. Nicht jeder braucht dabei einen System-Account. Da ist MySQL besser aufgestellt: Nutzer und Rechte können im System ganz einfach gepflegt werden. Postgresql muss neu konfiguriert werden, wenn ein Nutzer hinzukommt.

Navigation in der Datenbank

Ist man erst einmal in der Kommandozeile, gibts gleich tausend weitere Fragen: Wo bin ich? Was ist um mich herum? Wie bewege ich mich? Wie komme ich hier heil wieder raus? Wer hilft mir?

Beide Kommandozeilen bieten ihre Hilfe über die Tastenkombination \h an. Sehr praktisch – kein Umdenken. Die Ergebnisse unterscheiden sich jedoch gewaltig: Während MySQL eine kurze Übersicht über die Basic-Befehle ausgibt, öffnet Postgresql eine Hilfe-Shell mit vim-ähnlicher Syntax nur für SQL-Befehle. Mit einer solchen Shell kann kein Anfänger zurechtkommen! Hier macht Postgresql ganz schnell klar, für welchen Benutzerkreis es gedacht ist. Nix für NAU’s (Normalster anzunehmender User). Also muss man bei Postgresql externe Dokumentation bemühen. Wobei sich das auch bei MySQL empfiehlt. So fährt man bequemer.

Eine Auflistung aller Datenbanken gibts unter MySQL nach einem beherzten SHOW DATABASES; Postgresql schafft dies mit einem kurzen \l. MySQL kann man mit USE DATABASE; die Datenbank wechseln, bei Postgresql per \c (CONNECT). Die Tabellen einer Datenbank sieht man unter MySQL mit SHOW TABLES; unter Postgresql per \d. Was L mit Datenbanken zu tun hat, ist mir unklar, \d steht für DESCRIBE und erklärt auch einzelne Tabellen mit \d [TABELLENNAME]. Die Kürze der psql-Befehle ist natürlich bei der täglichen Benutzung von Vorteil. Hier wird wieder mal klar: Postgresql richtet sich an fortgeschrittene Nutzer, MySQL ist sehr einfach ausgelegt. Beide Datenbanken können per \q verlassen werden, MySQL zusätzlich über den Alias QUIT.

Tabellen und Datenbanken

Datenbanken werden von beiden DBMS per CREATE DATABASE [DATENBANKNAME] angelegt, per DROP DATABASE [DATENBANKNAME] gelöscht. Postgresql kennt dazu die externen Tools createdb und dropdb. Tabellen legt man analog dazu per CREATE TABLE [TABELLENNAME] an und löscht sie per DROP TABLE [TABELLENNAME]. Erklären kann man sich den Aufbau einer MySQL-Tabelle mit SHOW CREATE TABLE [TABELLENNAME], Postgresql kann dies wie bereits gezeigt per \d [TABELLENNAME].

Achtung: Sehr bekannt ist die Tatsache, dass sich Postgresql mehr an den SQL-Standard hält als MySQL. Doch was bedeutet das jenseits verschachtelter Abfragen und unverständlichem Spaghetti-Code? Zum Beispiel dies: Datenbank und Tabellennamen sind bei Postgresql grundsätzlich in Kleinbuchstaben gehalten. Namen mit Großbuchstaben sind durch Apostrophe einzuschließen. Wer also auf Namen wie ArtikelVarianten oder KalenderOptionen steht, sollte stets ‘ArtikelVarianten’ bzw. ‘KalenderOptionen’ schreiben oder auf eine andere Worttrennung umsteigen, wie den beliebten Unterstrich: kalender_optionen. Davon bin ich leider kein großer Fan, das sieht immer so oll aus…

Was ganz nett ist: Wenn man im MySQL-Client ein Query absetzt, so erhält man neben den Ergebnissen auch eine Anzeige, wie lange diese Anfrage gedauert hat. Hat man bei seiner Datenbank-Konzeption alles richtig gemacht, so sollte nur in wenigen Fällen etwas anderes als “(0,00 sec)” stehen. Der Postgres-Client psql schweigt an dieser Stelle per default. Mit dem Befehl \timing kann man die Zeitmessung aktivieren, erhält dann allerdings nur das Timing, nicht das Ergebnisset, allerdings auf die Mikrosekunde genau.

Das erste Fazit

Insgesamt macht MySQL einen sehr einfachen und leicht erlernbaren Eindruck, während Postgresl mit seinen Kurzbefehlen, seiner ungewohnten Syntax und oft komplizierten Administration Einsteiger eher abschreckt. Für den Power-User hält Postgres jedoch mehr Optionen bereit. Auf einem Level von Hobby-DB-Admins gesehen, sind beide Datenbanken natürlich voll funktionstüchtig und die Qual der Wahl zunächst wohl eher reine Geschmackssache. Wer Postgres mit PHP benutzen möchte, der sollte sich den Performance-Schlucker pg_connect() genauer ansehen – hier geht oft mehr Zeit verloren als beim Query selbst.

Und damit kommen wir auch schon zum Ende. In der nächsten Folge wird es um Datentypen und auch um ganz echte Daten gehen – denn dafür sind die Programme ja schließlich gemacht. Es lohnt sich also auf jeden Fall dranzubleiben!

Das ist allerdings nicht ganz so easy, wenn sich die Daten des Satzes in verschiedenen Tabellen befinden. Also muss man die sich mühevoll zusammenklauben. Bei uns im Shop sind es eigentlich nur eine Handvoll Tabellen: Der Artikeleintrag in der Warenwirtschaft, die Varianten, die Preise, Rabatte, Shop-Eintrag, Shop-Texte und Shop-Fotos.

Die Einträge wurden aus eben diese Tabellen zusammengesucht. Aus Performance-Gründen bieten sich hier Stored Procedures an:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT Timestamp INTO last FROM Tbl_XYZ INTO last WHERE xyz;
SELECT Timestamp INTO cur FROM Tbl_XYZ cur WHERE xyz;
SET last = IF(cur > last, cur, last);
…
RETURN last;
END$
DELIMITER ‘;’$

Natürlich schrumpft die Performance bei zunehmender Fragmentierung der Produktdaten erheblich, da die Berechnungskosten linear steigen. Aus diesem Grund habe ich überlegt, die Tabellen über INNER JOINS zu verknüpfen, und die Zeitstempel zunächst in einem Ritt zu holen:
DELIMITER ‘$’;
CREATE FUNCTION f_getModified(…xyz…) RETURNS Datetime READS SQL DATA
BEGIN
DECLARE last DATETIME;
DECLARE cur DATETIME;
SELECT a.Timestamp, b.Timestamp INTO last,cur FROM Tbl_XYZ a INNER JOIN TblXYZ b ON a.x=b.x AND a.y=b.y WHERE xyz;
SET last = IF(cur > last, cur, last);
RETURN last;
END$
DELIMITER ‘;’$

Auf meine 7 Tabellen angewendet, gibt das immerhin einen 10%-igen Performance-Schub. Nicht unerheblich, aber trotzdem nicht der Bringer. Anfangs waren es über 50% Geschwindigkeitsvorteil, als ich mit einfachen INNER JOINS über die ersten Tabellen arbeitete. Doch da es nicht immer entsprechende Einträge geben muss, ist man hier und da gezwungen, ein paar LEFT JOIN einzusetzen, welche als OUTER JOIN natürlich langsamer sind.

Ein weiteres Problem ist, dass nicht alle Tabellen einen Eintrag pro Produkt bieten, d.h. an dieser Stelle sind Sub-SELECTS vonnötigen, die den Zeitstempel über MAX(Timestamp) zunächst in der Ziel-Tabelle aggregieren, bevor der INNER JOIN einsetzt.

Letztendlich hatte ich bei einer entsprechend aufbereiteten Seite doch eher dazu tendiert, die bereits mit dem PHP-Script ausgelesenen Timestamps und die fehlenden Stempel per Hash-Scan zu ergänzen. An dieser Stelle konnte ich die Kosten für die Zeitstempel auf 20% der Procedure-Kosten drücken – allerdings ist diese Vorgehensweise nicht an allen Stellen die beste.

Doch bietet eine Seite nicht auch noch mehr? FAQs? Bewertungen? Mitkaufartikel? Hat sich die Seite nicht auch deswegen geändert, weil hier und da ein Eintrag dazugekommen ist? Was passiert, wenn sich eine Seite geändert hat, weil ein Eintrag wegfiel? Gar nicht so einfach, und ich möchte gern wissen, wie das “große” Shops so machen…Wer Ideen hat, ist zum Posten gerne eingeladen!