CacherouterIst nicht eigentlich ein Cache sondenr eben der Cacherouter. Der Cacherouter entscheidet, wo die Daten gespeichert werden. Ist der Cacherouter einmal eingeschalten, dann kann man problemlos von einem Cachingmechanismus zum anderen wechseln.
Um den Cacherouter richtig zu verstehen, muss man verstehen, was Drupal Cached; auch das ist simpel. Drupal Cache grundsätzlich Objekte oder ganzer HTML Code. Nehmen wir zum Beispiel eine Drupal Seite. Diese muss bei jedem Request neu gebaut werden, dazu wird die Datenbank entsprechend belastet und es entsteht eine Vielzahl an Queries. Endresultat ist der fertige HTML Code, welcher an den Besucher geschickt wird. Ist der Drupal Cache angeschalten, dann wird dieses HTML so wie es ist in die Datenbank gespeichert. Kommt der nächste Besucher, so kann lediglich dieses Stück HTML abgeholt werden und ausgeliefert werden.

Der Cacherouter entscheidet jetzt, wo genau dieses Stück HTML Code abgespeichert werden soll. Es wird nicht nur HTML iim Cache abgelegt sondern auch PHP Objekte/Arrays, welche vorher serialisiert werden.

Die Konfiguration des Cacherouters ist sehr einfach und es gibt diverse Beispiele auf der Cacherouter Projektseite.

APC als OP Cache
APC stellt sich als sehr unproblematisch heraus und lässt sich sehr schnell einrichten. APC ist primär ein OP Cache. Ein OP Cache speichert den interpretierten PHP Code, so dass der nicht bei jedem Aufruf neu geladen und interpretiert werden muss -> die CPU wird sich freuen. Installation von APC ist problemlos -> einfach mal Googeln.

APC und Cacherouter
Über den Cacherouter lässt sich APC auch als Objektcache verwenden, will heissen der HTML Schnippsel, bzw. das serialisierte Objekt wird nicht in der Datenbank gespeichert sondern im APC Memory. Daraus resultieren weniger Zugriffe auf die Datenbank. Auf der Projektseite des Cacherouters steht auch, wie man Cacherouter konfigurieren kann… sollte eigentlich verständlich sein.
Unter gewissen Umständen lässt sich APC nicht als Objektcache einsetzen. Wenn FastCGI eingesetzt wird und persistente Worker Prozesse verwendet werden, dann hat jeder dieser Prozesse seinen eigenen APC Memory -> APC kann daher nicht als Objektcache eingesetzt werden.

Memcache und Cacherouter
Memcache ist der grosse Bruder von APC und wird in vielen Projekten eingesetzt (unter anderem auch Facebook). Über den Cacherouter lässt sich Memcache gleich wie APC verwenden, will heissen, fertige HTML Schnippsel bzw. serialisierte Objekte werden im Memcache abgelegt. Der Vorteil von Memcache gegenüber APC ist jedoch, dass er nicht an einen Rechner gebunden ist: Ich könnte also einen dedizierten Rechner haben, welcher nur als Memcache dient und welchen ich von meinem Applikationsserver aus ansteuere.
Nehmen wir zum Beispiel ein Loadbalancing mit mehreren Webservern. Würden wir auf APC setzen, dann hätte jeder Server seinen eigenen Cache -> Wirkung ist nicht so hoch. Wenn wir jedoch einen dedizierten Memcache Rechner haben, welcher von allen drei Webservern verwendet wird ist die Effizienz um einiges höher.
Auch Memcache lässt sich über Cacherouter problemlos ansteuern. Memcache ist per se ein wenig langsamer als APC, was sich jedoch wierum relativiert, wenn man eben mehrere Webserver einsetzt.

Probleme
Klingt alles relativ einfach, aber es gibt auch ein paar Problemchen, welche mir in den letzten Wochen begegnet sind, zu denen ich zum Teil Lösungen gefunden habe, zum Teil nicht:

• APC mit FastCGI kann nicht als Objekt Cache genutzt werden, da jeder Prozess seinen eigenen Speicher hat.
• Cacherouter, Memcache und FastCGI ist nicht ganz ohne. Hier kommt nach wie vor ein 500er Error. Da muss wohl der Hoster noch ein wenig ran.

Weitere Möglichkeiten
Es gibt noch diverse andere Caches:

• Varnish (Ist ein Reverse Proxy)
• Squid
• xCache
• Zend Server
• und und und

Zu Varnish komme ich noch. Da bin ich noch dran, den zum Laufen zu bringen, bzw. Drupal (pressflow) dazu, dass es "gevarnished" wird.