nicht angemeldet
Hallo Eddi,
vielen Dank für deine sehr hilfreiche & ausführliche Erläuterung!
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.
ACK. Dies sollte imho auch immer einer der Grundsätze bei der Entwicklung/ Planung und Umsetzung sein.
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.
Na ja, man könnte es ja auch so formulieren:"Um ein Caching zu realisieren, erstelle ich jeweils ein statisches Dokument meines Dynamischen, solange sich an diesem nichts ändert!".
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. ;)
Dem stimme ich grundsätzlich auch zu: Dinge, die es schon gibt, muss ich nicht nochmal nachbauen! Oder anders formuliert: Ich will das Rad nicht neu erfinden. ;-)
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.
Das ist sicherlich auch eine effektive Maßnahme, die ich eigentlich auch immer verwende. Aber hat Content Negotiation nicht bei zwischengeschalteten Proxies das Problem, dass wenn nur eine Version gespeichert ist, der anfordernde Client u.U. entweder nicht die g-zippte Version bekommt, oder alle Clients nur die ungezippte Version? Wie kann man das umgehen/ vermeiden?
Kann man erreichen, dass ein Proxy beide Versionen speichert und abhängig vom Header, den der jeweilige Client mitschickt, die passende Version ausliefert?
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.
Ja, diese Methode scheint mir doch der ideale Kompromiss aus Aufwand und Nutzen zu sein. Wie oben schon erwähnt, könnte man (würde ich) das auch noch mit unter den Begriff "Caching" fassen.
BTW: Wie stelle ich es denn am einfachsten/besten/elegantesten an
- automatisch nach jeder Änderung (neuer Artikel, neuer Tag, neue Kategorie, bei Updates der vorgenannten Punkte) eine neue statische Version der betroffenen Dokumente zu erstellen?
- jeweils eine g-zippte Version davon auf dem Server zu speichern?
Das ist nun eine komplett anderes Konzept, was Du aus Deinen Fragen ersichtlich, sicher gehen wolltest.
Nein, so weit ist es gar nicht davon entfernt. Da es ja mit Sicherheit eine recht kleine Seite mit wenigen Besuchern wird, sollte sich der Aufwand dementsprechend in Grenzen halten. Trotzdem möchte ich es vom Grundprinzip her aber halt schon "ordentlich/ vernünftig" machen.
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.
Ja, grundsätzlich überzeugen mich die Vorteile dieser Methode(n) schon. Einziger Haken an der Sache, der mir jetzt auf Anhieb einfällt ist, dass wenn ich die (statischen) Dokumente mit einem Cache-Control oder Expires Header ausliefere, dann werden bspw. neue Kommentare auch erst nach Ablauf der angegebenen Zeitspanne für den jeweiligen Client "sichtbar". Und auch wieder das Problem mit den Proxies, oder?
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.
Na ja - einen der Hauptvorteile davon sehe ich halt darin, dass ich einen User "identifizieren" kann, was zwingende Voraussetzung für diverse andere Dinge ist. So könnte man bspw. auf noch ungelesene Artikel hinweisen oder einfach auch nur den "Komfort" für den User erhöhen. Denn eigentlich halte ich diese Sache noch für relativ "nebenwirkungsfrei" für den User.
Und wer das halt nicht möchte, kann ja auch durch eigene Entscheidung darauf verzichten (indem er bspw. den Cookie ablehnt, da ich bewußt auf trans_sid verzichte).
Gruß Gunther