Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 9

Die Grundlagen der Cache-Mechanismen: Caching in Ruby on Rails

Seite 4 / 7

Die Implementierung des Fragment-Cache-Stores ist wählbar: Der Standard ist das Ablegen der Keys als Datei im Dateisystem, was allerdings Schwierigkeiten beim Invalidieren macht, wenn mehrere Applikationsserver betrieben werden. Eine weitere Möglichkeit ist der Einsatz von „memcached“, einem sagenhaft performanten, über das Netzwerk anzusprechenden Datencontainer, der auch gern als Session-Store verwendet wird. Eine detailliertere Beschreibung der Optionen würde den Rahmen des Artikels sprengen, sodass hier auf die Hilfe im Internet verwiesen sei [1].

Auch die Invalidierung von Cache-Inhalten funktioniert bei Action-Caches analog zu den Page-Caches (wie auch das Schreiben von Observern):

RUBY

def update
		[...]
		expire_action :controller => 'mein', :action => 'index'
		[...]
	end

Listing 5

Bedingungsloses Caching?

Manchmal kommt es vor, dass nicht nur before_filter wie oben beschrieben vor dem Cache ausgeführt werden sollen, sondern dass das Caching nur bedingt durchgeführt werden muss. Das klassische Beispiel dafür ist eine Seite, die für eingeloggte Benutzer einen personalisierten Bereich enthält, der keinesfalls im Cache landen darf, während die Seite, wie sie sich anonymen Benutzern darstellt, durchaus zwischengespeichert werden sollte. Für den Fall bietet Rails leider keine mitgelieferte Lösung. Es wäre möglich, das Problem zu umschiffen, indem registrierte Benutzer auf eine andere URL weitergeleitet werden. Doch ist das auch nicht die optimale Lösung, denn unter Umständen sind viele Actions im Controller gedoppelt, was nebenbei dem REST-Design einer Applikation widerspricht. Die alternative Lösung ist das „conditional_caching-Plugin“ der kanadischen Firma Redline Software [2]. Nach der Installation wird die Anweisung „caches_action“ um den Parameter „:if“ ergänzt, mit dem eine Methode als Callback angegeben wird. So lassen sich Bedingungen definieren, die erfüllt sein müssen, damit das Caching greift. Das folgende Listing zeigt, wie das aussehen kann:

RUBY

class MeinController < ApplicationController
		caches_action :index, :if => :cache?
		[...]
		private
		def cache?
			!permit?('user')
		end
	end

Listing 6

Nur in Teilen: Fragment-Caching

Die letzte Ebene des Rails-Caching ist das „Fragment-Caching“. In Webanwendungen kommt es häufiger vor, dass bestimmte Seiten ihren Inhalt zum großen Teil aus dynamischen, benutzerabhängigen Daten beziehen, die sich nicht beziehungsweise kaum cachen lassen. Gibt es aber Bereiche auf den Seiten, die nicht personalisiert sind und gegebenenfalls aufwändig zu berechnen, liegt es nahe, nur diese Blöcke zwischenzuspeichern. Genau dafür existiert das Fragment-Caching. Um einen Block in einem Template zu cachen, wird folgender Code benötigt:

  • Seite:
  • 1
  • 2
  • 3
  • 4
  • 7

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden