Caching-Strategien, Komprimierungs-Strategien

[Michael Schröpl]

Hi Andreas,

Aber mit <meta> Tags im Dokument hjat das doch nicht viel Sinn, oder würdest Du denen bzw. den Browsern bzgl. dessen Befolgung genauso vertrauen wie HTTP-Headern?

nein, würde ich nicht. Ein Proxy-Server ist kein Browser und wird HTML-Dokumente nicht parsen.

Mein "Problem", ich habe keine festen HTML-Seiten, sondern das ganze ist _sehr_ dymanisch. Auf manchen Seite ändert sich die Ausgabe bei jedem Reload, und bei anderen kann sie sich zumindest jederzeit ändern. Das ist mir zu riskant, das werde ich wohl lieber nicht cachen. Anders ist es wie gesagt bei Grafiken, Javascripten und CSS.

Meine Expires-Definitionen sind sehr spezifisch pro MIME-Type. Für HTML liegen sie eher im Stundenbereich, für Graphiken eher im Bereich von Wochen ...

Und da lässt sich bestimmte ne ganze Menge machen, teilweise habe ich 4 Javascript-Links, 2 CSS-Links und unzählige kleine Grafiken auf der  Seite

Hast Du mal durchgerechnet, ob es sich rechnet, das Zeug einzubinden und komprimiert auszuliefern?

btw. - wenn ein Recourcenname in einer HTML-Datei mehrmals vorkommt wird doch nur _ein_ Request gestartet, oder?)

Hm ... das wird wohl auf den Browser ankommen. Es wäre zu hoffen, daß dieser selbst bei paralleler Anforderung der Ressourcen nichts doppelt abholt.

Kann ich eigentlich auch bestimmte Javascript-Dateien vom Caching ausnehmen, wenn ich das serverseitig konfiguriere?

Natürlich. (<FilesMatch> etc.)

Denn die Gefahr besteht ja durchaus, dass das man bevor der Browser wieder das Dokument neu anfordert, bereits was wichtiges ändern möchte, einen fatalen Fehler korrigiren will... daher würde ich HTML wohl grundsätzlich nicht cachen lassen.
Das Forum hier läßt sogar seine Hauptdatei 60 Sekunden lang cachen - man muß halt wissen, was man tun will.
Ist das immer noch so?

HTTP response headers received from server:
[ 17] HTTP/1.1 200 OK
[ 16] Server: Apache
[ 35] Cache-Control: public, max-age=60
[ 37] Date: Mon, 28 Jul 2003 09:19:00 GMT
[ 40] Expires: Mon, 28 Jul 2003 09:20:00 GMT
[ 46] Last-Modified: Mon, 28 Jul 2003 09:16:41 GMT
[ 19] Connection: close
[ 45] Content-Type: text/html; charset=ISO-8859-1
[ 26] X-Pad: avoid browser bug
[  2]

Ich muss gestehen ich habe es vergessen wie das genau funktioniert hatte, und leider kann ich das mit meinem Mozilla Firebird auch nicht  mehr einstellen. Es gab da aber definitiv 2 Einstellmöglichkeiten, einmal keep-alive, und einmal "chunked Irgendwas". Ich bin anscheinend auch etwas zu blöd mal ne anständige Dokumentation zu Mozilla online zu finden.

Ich kann mir nicht vorstellen, daß es Sinn macht, chunking im Browser einzustellen. Apache verwendet das bei SSI und CGI!

Das kenne ich und das meine ich sicher nicht. Es ging glaueb ich grob darum, dass ohne chunked encoding nach einem Request imme rgewartet wird, bis die Anwort vollständig da ist, bei chunked encoding ist das egal, da kann nach dem ersten Request sofort der nächste gestartet werden, ohne warten zu müssen dass eine Antwort auf den ersten eingegangen ist.

Der Browser stellt doch sowieso parallele Requests, und die meisten davon werden nicht "chunked" beantwortet werden. Also ist "warten" die absolute Ausnahme.

Was jetzt aber nicht komprimiert wird, sind die Javascripte(die teilweise auch etwas größer sind), und die CSS-Dateien. Wie komprimiere ich diese jetzt am besten?
Oft werden die eh nicht verändert, die Frage ist, ob es Sinn macht mod_gzip zu installieren, obwohl ich es nur für die Verhältnismäßig wenigen Dateien brauche.

Wie oben schon erwähnt: Rechne durch, ob es besser ist, das Zeug in PHP zu includen und dann gleich mit zu komprimieren, oder ob Du den separaten Caching-effekt haben willst.
Das Problem bei der Berechnung ist, daß Du Annahmen über die durchschnittliche Caching-Strategie Deiner Besucher brauchst - diese erhältst Du aus der HTTP304-Quote Deiner Zugriffe, _nachdem_ Du alles mit optimalen Expires-Headern versorgt hast ... je niedriger dieser Quote ist, um so besser ist Caching gegenüber Include+gzip.

2 Variante wäre mit Content-Negotiation zu arbeiten, d.h. ich erstelle manuell auch ...js.gz und ...css.gz Dateien, die ich dann mit "options multiview" in der httpd.conf des Apachen entsprechend ausgeben lasse.

Das ist halt aufwändig zu pflegen. (Es sei denn ... siehe unten.)

Noch eine Variante wäre es, die Komprimierung der HTML-Ausgabe der PHP-Scripte nicht PHP, sondern mod_gzip zu überlassen, was haltet Ihr davon?

mod_gzip 1.3.26.1a beherrscht _beide_ von Dir vorher beschriebenen Methoden und könnte Dir die statischen *.gz-Dateien automatisch herstellen und aktualisieren ... (Christians Implementierung!)

Eigentlich wäre das ja nicht nötig, also müsste der Weg mit PHP und kpl. ohne mod_gzip der effektivere sein, oder?

Es gibt schon Gründe für die Existenz von mod_gzip - trotz mod_deflate 2.0 ...

Viele Grüße
      Michael