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

Eine Webanwendung ist mit Ruby on Rails sehr schnell und komfortabel entwickelt. Was aber, wenn sie anschließend auch schnellen Erfolg hat? Was, wenn zum Beispiel die Erwähnung in der Presse für einen unerwarteten Ansturm sorgt – einen Ansturm, dem die Anwendung und die Server nicht gewachsen sind? Für diesen und ähnliche Fälle gibt es durchaus ein paar Dinge zu tun, um die Server auf die erhöhte Nachfrage vorzubereiten.

Unter Beachtung einiger Regeln skalieren Rails-Anwendungen gut mit zusätzlicher Hardware. Allerdings ist die Lösung unter Umständen teuer und sie erhöht durch den höheren Wartungsaufwand auch die Folgekosten. Günstiger ist in der Regel ein anderer Ansatz: das Caching, also das Zwischenspeichern. Dabei geht man davon aus, dass das Generieren der Webseiten, also das Ausführen der eigentlichen Webapplikation der „teure“, weil rechenaufwändige Vorgang ist, während das eigentliche Ausliefern der fertig „gerenderten“ Seite billig und schnell zu erledigen ist. Das gilt insbesondere, wenn ein Webserver wie Apache anstelle eines Applikationsservers die Arbeit erledigt.

Ganz einfach: Page-Caching

In Rails gibt es „out of the box“ drei verschiedene Ebenen des Cachings. An erster Stelle steht das performanteste, aber auch unflexibelste Verfahren, das so genannte „Page-Caching“. Page-Caching wird in einem Controller aktiviert, wobei die entsprechenden Actions zum Page-Caching angemeldet werden:

RUBY

class MeinController < ApplicationController
		caches_page :index
	def index
			[...]
		end
	end

Listing 1

Wird die index-Action das erste Mal aufgerufen, liefert Rails zunächst die Webseite aus, speichert sie aber gleichzeitig als HTML-Datei im Webroot des Webservers (üblicherweise das „public/“-Verzeichnis, in dem auch die Bilder, Stylesheets und JavaScripts der Applikation liegen). Beim nächsten Request wird bei entsprechender Konfiguration des Webservers statt der Anfrage an die Rails-Applikation die gespeicherte Webseite ausgeliefert. Der Request kommt also gar nicht erst bei der Rails-Applikation an.

Dass es schneller geht, eine statische HTML-Seite vom Apache-Server ausliefern zu lassen als von der Rails-Applikation leuchtet ein. Zweckmäßig ist das Vorgehen aber nur dann, wenn die Action unabhängig von irgendwelchen Session-Daten oder zusätzlichen URL-Parametern ist. Allerdings muss die Seite nicht notwendigerweise statisch beziehungsweise unveränderlich sein, da es durchaus möglich ist, innerhalb der Applikation Caches zu leeren.

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

Finde einen Job, den du liebst

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

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

Jetzt anmelden