"HTTP-Cache" für PHP-Applikation

[Sven Rautenberg]

Moin!

In diesen Zusammenhang solltest Du auch schauen, ob Deine Datenbank einen Spaltentyp kennt, der automatisch die letzte Änderungszeit des jeweiligen Datensatzes speichert (z.B. bei MySQL TIMESTAMP).

Ja, aber um das zu ermitteln muss ich eine Verbindung zur DB aufbauen, abfragen senden und Rückgabewerte analysieren...

SQL> select unix_timestamp(max(änderung)) from tabelle;
  PHP> if ($sql_änderung <= $browser_änderung)
           not_modified();

Finde ich gegenüber dem Erstellen einer "komplexen HTML-Tabelle" ganz und gar nicht aufwendig. Aber genau da besteht vielleicht auch Dein Problem: Du wirfst alles in einen Pott, ist ein Teil des PHP-Skriptes nicht zu gebrauchen, muß gleich der ganze PHP-Interpreter über Bord (übertrieben ausgedrückt).

Das Problem ist doch aber: Wenn sich nicht nur eine Tabelle ändern kann, sondern mehrere an verschiedenen Stellen, und diese Tabellen auch noch über ein komplexeres Framework zusammengestrickt werden (was unbestreitbar sinnvoll ist, weil das nämlich auch so Sachen wie OOP, Abtraktion in Klassen etc. umfaßt), und insgesamt also nur durch eine ähnlich komplexe Konstruktion überhaupt erfaßt werden kann, welche der möglichen Änderungen erfolgt ist, dann bringt es nichts, PHP-Anfängermäßig Simpelcode an den Anfang zu stellen. Interpretiert werden muß dann trotzdem der gesamte Code.

Was Sinn machen könnte: Wenn sich Seiten quasistatisch verhalten und nur selten Änderungen unterworfen sind, dann könnte man darüber nachdenken, einmal manuell oder genau zum Zeitpunkt der ersten Anforderung die erzeugte Seite exakt abzuspeichern als statische Kopie. Sozusagen "generieren lassen" auf Vorrat.

Allerdings: Genau dies passiert ja mit dem mod_rewrite-System. Nur wird hierbei sogar noch das tatsächliche Speichern der Seite eingespart, da die ja dem Client ohnehin bekannt ist, sofern er If-Modified-Since sendet.

Mir gefällt das vorgestellte Beispiel jedenfalls sehr gut. Dass man manuell die Cache-Flag-Dateien wegräumen muß, ist dabei nicht zu vermeiden. Dass es möglicherweise nur bei bestimmten Aktionen notwendig ist, sei zu analysieren.

Volldynamische Daten lassen sich damit jedenfalls kaum cachen - wäre ja auch nicht sinnvoll. Aber Caching-Header zu senden und auch sinnvoll auszuwerten, spart dem Server CPU-Zyklen und dem Benutzer Übertragungszeit ein. Beide gewinnen.

Warum sollte ich das alles nicht vermeiden - wenn es doch geht?

Siehst Du, "wenn es doch geht". Nur weil es geht, muß es ja noch lange nicht sinnvoll sein, oder?

Gerade weil es im Standard vorgesehen ist: Warum nicht verwenden?

2. Du versuchst, mit eine bestimmte Aufgabe zu erledigen, bedienst Dich dabei aber eines für diesen Zweck unzureichenden Werkzeugs.

Nein, das würde ich nicht sagen. Wenn die Feststellung seitens des Servers, ob die damals ausgelieferte Version noch aktuell ist, "teuer" ist, dann mag man sie sich zugunsten eines etwas zu aggressiven Cachings sparen. Immerhin erledigen sich mangelhafte Aktualisierungen durch ein forciertes Neuladen der jeweiligen Ressource von selbst: Kein If-Modified-Since - keine Cacheabfrage.

Warum? Deinen Ausführungen nach zu urteilen ist die ganze Angelegenheit fürchterlich komplex. Interpretersprachen waren noch nie für komplexe Aufgaben zu gebrauchen und werden es nie sein, egal wie c00l das Dingens gerade ist, insofern benutzt Du mit PHP möglicherweise schlichtweg das falsche Werkzeug. Oder, so würden es die SelfSpezialisten sehen, Dein Server ist zu lahm. Kommt im Endeffekt auf das gleiche raus.

Möchtest du den Interpretersprachen ihre Existenzberechtigung absprechen? Welche Sprachen würden denn deiner Meinung nach die Anforderungen für "komplexe Anwendungen" erfüllen?

Komplexität ist eine ziemlich komplexe Angelegenheit, würde ich meinen. Die läßt sich nicht einfach mit einem Schlagwort erschlagen.

Es mag Dir entsetzlich simpel vorkommen, aber das ist letztenendes genau das, was Du haben willst: keine Datenbankaufrufe, kein PHP, nicht einmal mod_rewrite. Daß auch solche statischen Seiten (in einem gewissen Rahmen) persönlich eingerichtet werden können, schrieb ich ja bereits.

Die Frage ist: Welche Informationen auf einer Seite sind dynamisch? Und _wie_ dynamisch sind sie? Ein Newsticker auf jeder Seite ist mit Sicherheit zu dynamisch, als dass man ihn mit statischen, immer wieder neu generierten Seiten abbilden könnte. Andererseits ließe er sich prima mittels SSI einbinden - und SSI kann natürlich auch PHP ausführen, mithin könnte eine Datenbank befragt werden.

Nur: Dann bin ich schon wieder fast genau dort, wo ich vorher war. Statische Seite startet PHP - Resultat ist dynamisch, kann nicht gecachet werden, und der kritische Teil, nämlich die Ermittlung der dynamischen Anteile, ist so oder so genauso Aufwendig. Einmal schreibt PHP die Seite komplett, ein anderes Mal nur einen Teil.

Wenn Andreas' Analyse ergeben hat, dass Cachen der Seiten sinnvoll ist, weil sich gewisse Aspekte einer Ausgabe nicht so häufig ändern, dann halte ich Caching-Header, die dies auf dem Client erlauben, sowie den frühestmöglichen Eingriff in die Request-Bearbeitung für absolut sinnvoll.

Die bekannten Nachteile sind dabei in Kauf zu nehmen und ließen sich eben nur durch komplett dynamisches Generieren lösen.

- Sven Rautenberg