Entwicklung & Design

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 Rails-RDoc zu den Fragment-Stores" href="http://rails.rubyonrails.com/classes/ActionController/Caching/Fragments.html" target="_blank">[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:

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!