nicht angemeldet
Meinung und Umsetzung: Caching
Guten Spätnachmittag SelfHTML-Forumsgemeinde,
ich weiß es gibt den Themenbereich "Meinung" und auch für den Umsetzungsteil meiner Frage wäre eventuell "PHP" besser geeignet, aber da meine Frage zwei Aspekte hat und ich Doppeltposting nach der Charta vermeiden wollte, habe ich mich für "Sonstige" entschieden.
Es geht um Caching. server- wie clientseitig, hierbei möchte ich 4 Seitentypen unterscheiden:
Typ 1: vollkommen statische Seite
Typ 2: Der eigentliche Inhalt der Seite bleibt statisch, jedoch gibt es dynamische Bereiche alla "Aktuelles Wetter". Sprich statische Seite mit einem regelmäßig dynamischen Block.
Typ 3: Dynamische Seite, z.B. Artikel mit der Möglichkeit Meinungen zu dem Artikel loszuwerden. Sprich die dynamische Seite lässt es zu, bestimmte zeitlich begrenzten Statischen Seiten anzunehmen.
Typ 4: Vollkommen Dynamische Seite, z.B. ein Formular, das jegliche Art von Input-Validierung mit Ausgaben, die den User jeweils auf den Fehler hinweisen, vornimmt, oder einen persönlichen Userbereich.
Hier wäre jetzt die Möglichkeit die Meinungsfrage unterzubringen:
Für welche der Typen findet ihr serverseitiges Caching sinnvoll?
Für welche der Typen findet ihr clientseitiges Caching sinnvoll?
Sonsige Meinungen?
Nun zum Umsetzungsteil:
Bei meinem miniCMS besteht jedes Seite, aus einem Template, das bestimmte "Blöcke" erfordert. Sagen wir Inhalt, Meta-Angaben, eigene CSS und/oder Javascript. Diese Blöcke können sich unendlich tief selber wieder einschließen - Inhalt umfasst zum Beispiel die Blöcke Text, Fußzeile, Kopfzeile. Jeder Seite werden diese Blöcke zugeordnet, wobei zum Beispiel allen Seiten der Block Fußzeile zugeordnet wird.
Jeder Block erhält den aktuellen Timestamp bei einer Änderung.
Nun ist meine Frage, ob es sich lohnt, sofern es sich um Zusammensetzungen von statischen Blöcken aus einer Datenbank handelt, serverseitiges Caching z.B. in einer Datei überhaupt sinn macht?
Des Weiteren Frage ich mich, ob ich immer den jüngsten der Blöcke-Timestamps als Modified-header senden soll oder nicht?
Macht es bei dynamischen Teilen Typ 3 Sinn, diesen Teil als Unter-Block zu Cachen?
Ich weiß das klingt alles wirr, aber ich weiß nicht, ob es Sinn macht wirklich nur komplette Seiten vom Typ 1 zu Cachen. Oder ob es z.B. auch Sinn macht den Block Navigation, der aus einer NestedSets-Tabelle erstellt wird Sinn macht diesen zu Cachen, da dort die richtige Umsetzung und Schachtelung und Aufklappung doch etwas Zeit benötigen kann.
Mir geht es um das Grundprinzip, und wie im heutigen WWW, wo es kaum noch Seiten gibt, in denen man noch nichtmal einen dynamischen "Spruch des Tages"- oder "Wetter des Tages"-Block findet.
Grüße
-
Erstmal musst du sehen, dass das HTTP Protokoll nichts weiss von "Seiten". Es kennt nur Ressourcen, die unter ihren urls anforderbar sind. Zu jeder URL gilt damit eine lastmodified Information.
Bei einer url muss man unbedingt Querystrings als Teil derselben berücksichtigen. Ebenso gilt, dass Formulardaten ebenfalls automatisch einen neuen Request bringen.In deinem CMS hast du aber ein anderes Konzept. Du hast einen 'Masterrequest' der andere Requests zur Folge haben kann (CSS, JS, Bilder etc...).
Dich interessiert aber nun dein Masterrequest, der inline aus verschiedenen Komponenten zusammengesetzt sein kann. Für welche Komponenten lohnt sich serverseitiges Caching?
Es lohnt sich dann, wenn das Einlesen aus dem Cache und die Verwaltung des Caches weniger CPU/RAM/Nerven verschleisst, als die adhoc Produktion.
Mehr kann man nicht sagen. denn involvierte Datenbanken etc, spielen da ein Wort mit.Ich selbst betreibe ein Caching für sehr rechenintensive Aufgaben. Aber es gibt bei mir effektiv nicht sehr viel, dass ich cachen kann.
mfg Beat
-
Ebenso gilt, dass Formulardaten ebenfalls automatisch einen neuen Request bringen.
Heißt das, dass ich die Formularseite vom Client ganz normal Cachen lassen kann, da ein Request mit Post-Daten zu ein "anderer" ist?
Gruß
-
Ebenso gilt, dass Formulardaten ebenfalls automatisch einen neuen Request bringen.
Heißt das, dass ich die Formularseite vom Client ganz normal Cachen lassen kann, da ein Request mit Post-Daten zu ein "anderer" ist?
In der Regel braucht man kein spezielles expires zu senden.
Diese Regel kann nun aber wieder Ausnahmen haben. Das lässt sich halt nur im konkreten Fall beantworten.
--Ist eine Session im Spiel
--Wird diese via Cookies oder via url QueryString transportiert.
--Ist es un/erwünscht, dass der User die Browserback Funktion verwenden kann, ohne dass ein neuer Request vom Server erzwungen wird.mfg Beat
-
-
-
Ich implementiere gerade ein Caching im Umfeld von PostgreSQL(8.3.3) und Oracle(10R2) XML-Views.
Das Grundproblem intensiver XML-Verwendung ist, dass ständig große Strings parsed werden müssen:
- DOM wird serverseitig erzeugt: zumindest "1/2-mal" Parsing, nämlich auf valide PCDATA/CDATA
- DOM wird per XSLT transformiert: zumindest 1x Parsing wenn das XSL selbst schon parsed ist; sonst 2x Parsing; die XSLs sind nicht unbedingt billiger als die XML-Nutzdaten
Den Overhead kann ich bei der Laufzeit-Erwartung "Viele SELECTs, wenige INSERTs" resp. "Multiple READ, few WRITE" reduzieren, zumal PostgreSQL Trigger in Python und Perl unterstützt und somit praktisch jeder IPC-Mechanismus zur Invalidierung einer Cache-Line genutzt werden kann.
Fürs Orakel muss ich da noch etwas zaubern (und Doku lesen).Grüsse
Solkar