nicht angemeldet
Hi Sven!
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.
Ich überlege auch, ob ich ob ich das ganze noch weiter ausbauen könnte. So wie es jetzt ist wird pro Session jedesmal eine neue Version erzeugt. Ich könnte das auch komplett user-basiert machen, also nicht die Session, sondern die User-ID als Identifikations-Merkmal verwenden. Dann könnte ich die Cache-Dateien ggfs. Session-Übergreifen verwenden. Dann muss ich nur in der RewriteCond irgendwie an die UserID kommen, das könnte ich entweder über REMOTE_USER erfahren, oder allgemeingültiger(also auch ohne HTTP_AUTH) über eine bei Logins dynamisch gepflegte RwriteMap. Erst dachte ich das sei sicherheitstechnisch nicht das wahre, aber das ist ja unbegründet, ein entscheidender Vorteil der 304-Methode liegt ja darin, dass der Client eine lokale Version haben muss, die er nur erhält wenn er einmal durch den normalen Authentifizierungs-Prozess gegangen ist.
Problematischer ist da schon, dass der User evtl. verschiedene Browser mit verschieden alten Versionen verwenden könnte. Das kann ich mit der aktuellen Version nicht abbilden. Hierzu müsste ich entweder If-Modified-Since oder Etag auswerten. Aber da weiß ich im Moment nicht, wie diese Information sinnvoll speichern kann. Oder woher ich die überhaupt bekomme!
Eine Möglichkeit wäre es, an der Stelle wo ich die Flag-Datei erzeuge, selber einen Last-Modified Header zu erzeugen, dessen String ich dann mit im Dateinamen speichern kann. Wobei mir das nicht so geeignet erscheint, aufgrund der ganzen Leerzeichen im String, da wüßte ich jetzt nicht wie ich das machen könnte. Aber dafür gibt es ja den Etag Header, den kann ich ja einfach senden. Und da kann ich ja einen entsprechend einfachen String nehmen, den ich an den Dateinamen hänge. Müsste da ggfs. noch die Protokoll-Version prüfen.
Soweit so gut. So könnte ich es also erreichen, dass wenn sich die Ausgabe eines Scriptes über die mehrere Sessions hinweg nicht ändert, dass immer die Version im Cache verwendet wird, und sollte dank Etag Header auch keine Probleme mit Usern haben, die verschiedenen Clients verwenden. Das halte ich durchaus für sinnvoll. Etwas weitergedacht könnte man bei einer zu cachenden Seite auch die HTML-Ausgabe per Output-Buffer Funktionen in der Datei mit dem genannten Namen speichern, dann könnte ich einem User, der einen anderen Client verwendet eben diese HTML-Seite ausliefern, ohne auf die Applikation zurückgreifen zu müssen. Das stellt zwar kein großes Problem da, nur wird das Cache-Verzeichnis hierdurch schnell erheblich größer. Und da ich davon ausgehe dass die User eher selten den Client wechseln, halte ich den Aufwand eher nicht wirklich für gerechtfertigt, oder?
Naja, habe viele Ideen, ich überlege auch ob ich in meiner Anwendung die normalen SessionIDs abschaffen soll, denn ich verwende sowieso durchgehend SSL, und da habe ich in PHP ja Zugriff auf die SSL_SESSION_ID, die könnte ich ja an die Funktion session_id($_SERVER['SSL_SESSION_ID']) übergeben, das hätte den Vorteil dass ich mir auf der einen Seite Cookies spare, auf der anderen Seite den Mehraufwand von TransSID, was ja durchaus einen gewissen aufwand darstellt, da die gesamte HTML-Ausgabe der PHP-Scripte ja durch einen Filter laufen muss.
btw., falls es Dich interessiert, ein paar Tipps zur Optimierung von PHP/Apache-Performance findest Du hier:
http://phplens.com/lens/php-book/optimizing-debugging-php.php
http://php.weblogs.com/tuning_apache_unix
Grüße
Andreas