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.

Am besten führt man den Besucher also gleich an die richtige Stelle. Und dieser Mechanismus heißt Redirect. Mit einfachen Boardmitteln (entweder in der .htaccess mit mod_rewrite oder mit PHP), die man auf fast allen Webservern findet, lässt sich ein Redirect in Sekundenschnelle einbauen. Ich vergesse auch immer wieder, wie man einen korrekten Redirect setzt. Und dann stückele ich mir das zusammen. Deswegen hier ein PHP-Script zur Zusammenfassung:

<?php
   header("HTTP/1.1 301 Moved Permanently");
   header("Location: http://www.neue-domain.de/");
   header("Connection: close");
   exit();
?>

Gut ist es, den Redirect mit Status 301 (permanent) zu setzen, ein 302 (temporär) könnte bei Suchmaschinen schnell nach hinten los gehen. Das PHP-Schnippselchen wird einfach an den Anfang der alten Webseite gesetzt. Wichtig: Davor darf wirklich gar nichts über den Äther gegangen sein. Auch keine Leerzeilen – sonst greifen die HTTP-Header-Angaben nicht.

301 Redirect in der .htaccess

Ein anderer Mechanismus nutzt die Fähigkeiten des Webservers. Für einen Apache-Webserver macht man einen Verweis über einen Eintrag in der Datei .htaccess im Document-Root-Verzeichnis der alten Domain. Dort gibt man dem Rewrite-Modul eine Regel (RewriteRule) mit, welche aus der alten URL eine neue schreibt:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)$ http://www.neue-domain.de/$1 [R=301,L]
</IfModule>

Zuerst der linke Teil: Die Regel ^(.*)$ bedeutet: Alle angesprochenen Unterseiten .* zwischen Anfang ^ und Ende $ sollen der neuen Domain übergeben werden. Deswegen die Klammer darum. So kann im zweiten Teil der Regel mit $1 auf die erste Klammer der linken Regel Bezug genommen werden. Dadurch wird zum Beispiel aus http://www.alte-domain.de/start.php ein Verweis auf http://www.neue-domain.de/start.php.

Der Schalter [R=301] setzt wieder den Permantenten Redirect (das verstehen die Suchmaschinen und ändern ihre Einträge). Dabei signalisiert [L], das es sich bitte um die letzte anzuwendende Regel handelt, danach soll Apache bitte mit Rewriting aufhören. Meistens ist er brav und tut das dann auch.

Denn viele Seiten benutzen google-analytics oder etracker, um das maximal Messbare aus ihren Nutzern herauszupressen. Wer Lust hat, mitzumachen, bitteschön. Wer nicht, kann durch ein paar simple Zeilen in der Datei /etc/hosts sein Leben als Surfer etwas ruhiger gestalten. Dazu trägt man einfach die nicht erwünschten Servernamen mit lokalen Adressen ein, hier ein Beispiel:

127.0.0.101        www.etracker.de
127.0.0.102        www.etracker.com

Ein ganz globaler Vorteil: Das Laden dieser Seiten geht nun wesentlich schneller.

Jetzt höre ich schon wieder Stimmen in meinem Kopf, die rufen: Warum denn per Hand? Gibts das nicht als Browser-Plugin (wie ein Ad-Blocker), oder als Gnome-Widget? Oder als Kommandozeilen-Tool? Warum schon wieder selber was machen? Nun, dass zwei Zeilen die wohl allerallerkürzeste Variante sind, das sei wohl hiermit bewiesen. Aber es gibt ganz praktische Gründe für diese Lösung.

Ein Vorteil gegenüber iptables (dem Firewall-Mechanismus von Linux) ist, dass unser Rechner immer einen 404-Fehler meldet, solltet Ihr nicht wahnwitzig genug sein, den etracker nachzubasteln. Der Browser bekommt also, was er möchte, nämlich eine Antwort, egal welcher Art. Würde man eine Adresse per iptables eliminieren (-j DROP), so bliebe der Browser im Zweifelsfalle hängen.

Vorteil gegenüber einer Browser-integrierten Option ist, dass dies gleich für alle anderen Browser, Newsreader oder Email-Clients ebenso funktioniert. Und…ich könnte jetzt noch die übermittelten Daten aus dem Apache-Log aggregieren: Was will eine Seite über mein Verhalten wissen? Man könnte dann auch mal die Webmaster der Server fragen, warum sie sich so Daten-krakig verhalten und Ihnen die Logs gleich mitschicken.

Einziger Nachteil: Man muss root sein – aber das ist ja nun fast jeder…

Umso erstaunlicher, dass ich selbst seit einigen Tagen an einer Web 2.0 Seite im Intranet unserer Firma bastle. Und ich muss zugeben, Web 2.0 hat etwas.

Am erfreulichsten fand ich die Tatsache, dass man keinen Installationsaufwand hat. Man braucht weder Servlet-Container, Apache-Module noch irgendwelche anderen Erweiterungen auf dem Server, sondern alles läuft auf der Programmier-Ebene ab. Zumindest die technische Seite von Web 2.0 kann auf folgenden Satz reduzieren: Man instanziiert eine Javascript-Klasse namens XMLHttpRequest, führt über die Methoden open() und send() einen asynchronen Request aus und verarbeitet dessen Response auf der bestehenden Seite. That’s it.

Klar, neben dem Request ist vor allem der JS-Code das schwierigste, um den per Response erhaltenen Content ordentlich auf der bestehenden Seite einzubauen. Hier bin ich bisher komplett ohne XML oder XSLT gefahren (also AJ statt AJAX), habe den Response in Stino-HTML erzeugt und einfach in ein dafür angelegtes Seiten-Element als innerHTML reingeworfen. Im Response eingebaut war dann auch schon der Code, um diesen per JS-Aufrufe weiter an andere Elemente zu verteilen. Mit etwas Nachdenken kann man hier mit ein, zwei Übergabeparametern (Element-ID’s, Präfixe) wunderbar generisch arbeiten, so dass sowohl die erstellte Request-Technologie als auch der Management-Code ausgelagert und für mehr als nur eine Seite nutzbar gemacht werden können.

Man kann also ganz klein und leicht beginnen, sich ein paar generische Abfragen und eine JS-Skript-Datei erstellen und schon hat man neue, interessante Werkzeuge, die man sogar noch ganz leicht in bestehende Seiten einbauen kann. Damit das ganze flüssig läuft, habe ich die Indizes unserer Tabellen auf die Abfragen hin ergänzt. Der Faktor der Beschleunigung betrug etwa 2 bis 3! Die schnellen Abfragen ohne JOIN machen dann auch richtig Spaß – es flutscht einfach mal.

Der einizige Nachteil ist natürlich: Der Anwender braucht Javascript! Und der Browser muss auch noch der Site vertrauen. IE7-Nutzer müssen die Seite also evtl. explizit eintragen. Daneben braucht der Nutzer evtl. noch Session-Cookies, damit man mit PHP auch noch die Ergebnise bequem weiterverarbeiten kann, ohne sich die Finger wund zu coden. Im firmeneigenen Intranet ist das alles weniger kritisch, hier kann man die Anforderungen selbst abschätzen/austesten, definieren und für alle verbindlich umsetzen.

Als nächstes gehts weiter mit der Praxistauglichkeit. Wie skaliert das ganze, wenn es auf einem stark frequentiertem Server läuft? Wie stark sind die Latenzen des Netzes? Sollte sich herausstellen, dass flüssiges Arbeiten möglich ist, eröffneten sich uns dadurch ganz neue Möglichkeiten, vor allem bei der Einbindung externer Partner.

Also schnell weiter machen…Tschüß!