/ (APACHE) Caching von Seiten - wann und wie?

[Edgar Ehritt]

Hallo Guther,

es lohnt meines Erachtens sich darüber Gedanken zu machen, auch wenn man nicht für das Serverhosting Verantwortung trägt, Ressourcen möglichst sparsam einzusetzen. Auch wenn dies nicht wirklich notwendig ist, so hat es doch einen ungemein lehrreichen Charakter. ;)
 Generell würde ich die Frage nach dem caching mal hinten anstellen und viel grundsätzlicher herangehen. Dann stellt sich die Frage: Statisch oder dynamisch.

Statische Dokumente werden gegenüber dynamischen sehr ressourcenschonend serviert. Sie bringen durch die Möglichkeiten der allermeisten Webserver (in in Deinem Fall, dem Apachen, sowieso) "nativ" erhebliche Vorteile mitsich. An dieser Stelle verweise ich mal auf den entsprechenden Teil des Artikels von Christian Kruse, um kurz die Vorteile darzustellen.

Generell geht es Dir ja um caching. Wie zu sehen ist, bringen statische Dokumente dieses per HTTP-Header Etag und Last-Modified mit, zum Preis eben _statische_ Inhalte zu haben. Dieser Mechnaismus müsste bei dynamischen Dokumenten erst erstellt werden (was aber auch möglich ist, nur warum sollte man? ;). Kurz umrissen, müssten dann alle eingebundenen Dateien (bei Dir ja eher Datenbanksätze) und Daten ($_REQUEST, $_SERVER) für das Generieren eines Etag-Headers zu einem Hash herangezogen werden. Damit hätte man zwar dynamische Inhalte, jedoch sollte man immer(!) davon ausgehen, dass zwischen Endnutzer mit seinem Browser und dem Webserver auch Proxies zwischengeschaltet sind (AOL). Somit hat man eben auch für einen korrekten Vary-Header zu sorgen. Alles in allem ist dies möglich (persönlich aber wäre es mir bei einer Artikelsammlung zu viel Aufwand).
 So favorisiere ich den Etag i. V. m. statischen Dokumenten, da er eine Integritätsprüfung darstellt und somit, die von Dir angesprochene Frage, was man gar nicht cachen sollte, sich erübrigt.

Das heißt also, ich würde vor jedem noch so ausgeklügeltem Cache-Mechanismus statischen Dokumenten den Vorrang geben. Der Grund liegt auf der Hand: Ums cachen kümmert sich allermeist nämlich der Browser selbst. Also kann ich mich den Inhalten widmen. ;)

Den zweiten, nicht unwesentlichen Punkt bei einem CMS sehe ich bei der Datenkompression. Komprimierte Dokumente werden sehr schnell und bandbreitenschonend durch die Leitungen gejagt. Der Standard heutiger Browsergenerationen besteht im Akzeptieren von komprimierten Inhalten. So senden alle entsprechende Accept-Encoding-Header. (Ja, es hat nichts mit Deinem eigentlichen Ansinnen zutun - ich hallte es dennoch für eine Überlegung wert.) Dies ist ein weiterer Vorteil von statischen Dokumenten, dass man nicht on-the-fly für Kompression zu sorgen hat.
 Allermeist kommt PHP auch mit der Erweiterung für die Zlib daher. Durch PHP erstellte statische Dokumente sollten also zum einen unkomprimiert auf dem Webspace gelagert werden, wie auch in ihrer komprimierten Entsprechung. Für das korrekte ausliefern muss man wiederum keine eigenen Codes erstellen, sondern es reichen auch hier wieder die bordeigenen Mittel der meisten Webserver für Content Negotiation aus.

Die Herangehensweise ist also recht simpel umrissen: Erstelle Dir Templates fürs Layout in dem der jeweilige Inhalt durch PHP eingesetzt wird. Jedoch sollen die so erzeugten Dokumente nicht jedes mal neu erstellt, sondern auf dem Webspace statisch hinterlegt werden. Bei jedem Ändern eines Artikels, müssen nur die entsprechenden Dokumente überschrieben werden. Soweit dies auch sich häufig ändernde Menüeinträge betrifft, heißt dies zwar ein relativ häufiges Überschreiben der Dokumente, jedoch gleicht sich dies eben durch die oben schon erwähnten HTTP-Mechanismen sehr komfortabel aus.

Das ist nun eine komplett anderes Konzept, was Du aus Deinen Fragen ersichtlich, sicher gehen wolltest. Meiner Ansicht nach lohnt es dennoch mal darüber nachzudenken, ob man für ein paar Artikeln, wenn man sich schon Gedanken um caching macht, nicht besser statische Dokumente erstellt.

Session: Selbst sehe ich die heutigen Zustände, wo ich alle Kekse selbst abnicke/ablehne, mit Argwohn, dass für den Nutzer überwiegend Grundlos auf 80% aller Sites Session genutzt werden. Da bitte ich wirklich in Dich zu gehen, ob bei einem reinem Lesezugriff, Sessions sein müssen.

Gruß aus Berlin!
eddi