Ein Objektcache hält das ERGEBNIS der Arbeit im Speicher, damit die nächste Anfrage sie nicht wiederholt. Auf einer Website, die der Datenbank auf jeder Seite dieselben Fragen stellt, ist die Wirkung groß. Auf einer Website, deren Seiten aus anderen Gründen langsam sind, ist sie null.

Wann es hilft

  • Ein CMS, das bei jeder Anfrage Dutzende Einstellungszeilen lädt - WordPress fragt seine Optionen auf jeder einzelnen Seite ab.
  • Menüs, Taxonomien, Benutzer-Metadaten: klein, wiederholt, identisch.
  • Sessions, aus denen sonst Tausende kleiner Dateien auf der Platte werden.

Wann nicht

Eine Seite, die wegen EINER Abfrage über eine große Tabelle langsam ist, bleibt genauso langsam. Der Cache spart wiederholte Arbeit, nicht teure Arbeit. Reparieren Sie zuerst die Abfrage; sie zu cachen verbirgt nur, wie schlimm sie ist - bis der Cache kalt ist.

Ein Speicherlimit und eine Verdrängungsregel setzen

maxmemory 256mb
maxmemory-policy allkeys-lru

Ohne maxmemory wächst Redis, bis der Maschine der Speicher ausgeht, und der Kernel bringt dann etwas um - oft die Datenbank. allkeys-lru wirft stattdessen den am längsten unbenutzten Schlüssel weg, und genau das soll ein Cache tun.

An localhost binden

Redis hat standardmäßig keine Authentifizierung. Ein aus dem Internet erreichbares Redis ist eine offene Tür: Man kann ihm sagen, es solle Dateien schreiben. Binden Sie es an 127.0.0.1 und verlangen Sie ein Passwort.
bind 127.0.0.1
requirepass a-long-random-string

Prüfen, ob er wirklich benutzt wird

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

Treffer weit über Fehlgriffen heißt, es funktioniert. Überwiegen die Fehlgriffe, laufen Schlüssel zu schnell ab oder etwas leert den Cache bei jeder Anfrage.

Ein Seitencache und ein Objektcache sind zweierlei. Ein Seitencache liefert eine ganze fertige Seite aus und hilft anonymen Besuchern; ein Objektcache hilft angemeldeten, deren Seiten sich nicht teilen lassen.