Caching mit WebsiteBaker

Caching von Abschnitten (Sections)

Einige Module verursachen beim Aufruf sehr viele Datenbankzugriffe, möglicherweise noch gepaart mit umfangreichen String-Operationen (Suchen-Ersetzen usw). Gerade beim Billig-Hoster mit „Schnupper-PHP“ kann der Seitenaufruf zur Kaffeepause werden.

Noch schlimmer wird es, wenn Module auf entfernte Inhalte zugreifen, wie etwa der Inline-Wrapper: Server A arbeitet bis zu einem Punkt, ruft eine Seite auf Server B auf, dieser setzt wiederum sein Werkel in Gang und schickt die Seite zurück, erst dann kann Server A wieder weiterarbeiten.

Viel schneller wäre es, den Inhalt der Section insgesamt in ein Datenbank-Feld zu schreiben und „as is“ abzurufen. Das Problem an der Sache: Wann soll der Cache neu geschrieben werden? Beim Gästebuch wäre das einfach: Wenn ein Eintrag gespeichert wird. Was aber, wenn das Gästebuch mehrseitig ist? Schon schwieriger, aber noch machbar.

Beim Inline-Wrapper könnte das zb stündlich oder täglich gemacht werden, etwa per Cron-Job. Eine derartige Vorgangsweise hätte noch einen weiteren Vorteil: Wenn die entfernte Seite nicht (mehr) verfügbar ist, hat man zumindest den letzten Stand, statt die Fehlermeldung anzuzeigen.

Caching ganzer Seiten:

Das Prinzip ist relativ einfach: Mit einer modifizierten index.php wird der komplette Inhalt nicht ausgegeben, sondern es werden mit etwas  str_replace die  Pfade zurechtgebogen, einige Modifikationen gemacht (etwa die URLs gekürzt) und dann alles in statische Dateien geschrieben.

Diese Seiten sind dann „echte“ .html-Seiten, haben also einen normalen http-header mit Änderungsdatum und allem drum und dran. Und: Sie werden vom Server wesentlich schneller ausgeliefert.

Ein weiterer ganz wesentlicher Vorteil dabei: Besucher sehen nicht das CMS, sondern die gespeicherten Seiten. Der Redakteur kann im Hintergrund arbeiten; erst wenn er die Seite veröffentlicht, wird sie sichtbar. Selbst wenn das ganze CMS zusammenbricht (etwa nach einem Update): Die statischen Seiten sind unberührt vorhanden.

Allerdings sind auch die Nachteile erheblich: Zeitgesteuerte Veröffentlichung, Gästebuch, Kommentare: Alle wirklich dynamischen Funktionen eines CMS sind problematisch bis unmöglich in so ein System zu zwingen.

Es geht gerade noch, Gästebuch-Eintragswillige ins CMS umzuleiten, allerdings ist es mir bisher noch nicht gelungen, den Eintrag dann auch gleich freizuschalten.

Meine Praxis

Für Kundenseiten wende ich durchwegs Caching ganzer Seiten an, vor allem um dem Kunden dieses Sicherheitsnetz zu bieten. Da Firmen-Präsenzen kaum Gästebücher oder Kommentarfunktionen verwenden, halten sich die Nachteile in Grenzen. Auf einigen Seiten verwende ich Cron-Jobs, um etwaige Veränderungen täglich automatisch zu veröffentlichen.

Caching von Abschnitten: Etwas ähnliches wende ich im Modul „Members“ an. Das Vorgehen ist relativ simpel: in der view.php wird nach dem Cache gefragt; wenn vorhanden: ausgeben, sonst: Section aufbauen, in den Cache schreiben und dann ausgeben. Die Aktualisierung erfolgt also durch simples Löschen des Caches, beim nächsten Aufruf der Seite.

Ahja: (Falls jemand fragt...)

Es gibt hier keine „konkrete“ Anleitung, weil ich a) nicht immer alles herumerzählen muss – und b) die Anpassungen so umfangreich sind, dass ich hier ohnehin keine Copy&Paste-Lösung bieten kann.

Comments

Add Comment

Statische Seiten aus Websitebaker

Caching ganzer Seiten bietet einige Vorteile - und einige Nachteile. Im Fall der Site vienna-replugged.at überwiegen die Vorteile, weil per Inline-Wrapper auf umfangreiche Inhalte von anderen Domains zugegriffen wird.

Ein Schritt weiter:

CMS und statische Seiten auf verschiedenen Domains? Ja, natürlich: Wenn man schon ganze Seiten speichert, funktioniert das auch über Domains hinweg.