Cache für dyn. Inhalte und für Bilder

Hallo zusammen,

beim Titel wusste ich ehrlich gesagt nicht was sich da genau reinschreiben soll, aber es geht im wesentlichen um das Thema Cachen von dynamischen Inhalten (Server / Client) und dem Cachen von Bildern.

Ausgangssituation:

Server-1: Auf dem sind alle Bilder gespeichert. Diese werden auch mit "Expires + 6 Monate" ausgeliefert, damit diese nicht bei jedem Zugriff neu angefordert werden.

Die Bilder werden auf verschiedenen Domänen verwendet, die diese jeweils vom Server-1 laden. Soweit so gut.

Im Kundenbereich können die Bilder geändert werden. Ist selten, kommt aber vor. Diese geänderten Bilder sollen dann natürlich auch angezeigt werden. Der Browser-Cache verhindert das aber. Es kommt wieder das alte Bild, bis der "Expires" überschritten wird.

Lösungsansatz und daraus resultierende Probleme:
1. Den Bildern jeweils neue Namen geben ( etwa per time().jpg )
-> Problem. Das serverseitige Cachen der HTML-Seiten geht nicht mehr oder nur unzureichend, da das hinterlegte Cache-File dann bis zu seinem Ablauf einen falschen Bildnamen enthält

2. Den Bilder einen Parameter anhängen ( etwa 44.jpg?time() )
-> Problem. Die Bilder werden dann im Kundenbereich zwar sofort aktualliesert, aber auf den eigentlichen Webseiten nicht. z.B. "/bild/44.jpg" wäre dort noch immer das alte vom Browser-Cache. Um das zu umgehen müssten auch bei den ganzen Webseiten Parameter angehängt werden, aber dann funktioniert natürlich das serverseitige Cachen wieder nicht, da die Inhalte sich quasi sekündlich ändern.

3. Expires auf Server-1 abschalten
-> Problem: Die Bilder werden dann immer neu geladen. Sind einige tausende und würde unnötig Last und Traffic erzeugen

Hm, nun stehe ich da wirklich vor einem Problem und weiß nicht wie ich das angehen soll.


Ein sich ständig ändernder Dateiname ist eigentlich unschön, denn die Bilder werden auch extern verlinkt und würden so immer wieder zu Fehlern führen. Server-Cache geht auch nicht.

Mit Parametern funktioniert es nicht auf den einzelnen Webseiten oder der Server-Cache geht nicht.

Hat da einer von euch einen Ansatz? Ich sehe da wohl den Wald vor lauter Bäumen nicht mehr?

Nachtrag, da eben erst bemerkt:
Ein Bild ist online. Wird im Browser angezeigt. Dann wird das Bild im Kundenbereich geändert. JETZT lösche ich manuell den Cache vom FireFox (Disk cache device -> Number of entries: 0). Ok, der Browser-Cache ist leer. Rufe ich das Bild nun nochmal auf, denn kommt dennoch das alte Abgesehen von meinen oben genannten Problemen, wo kommt da denn nun das alte Bild her?

Danke und Gruß,
Ingo

dann nimm doch zusätzlich zu mod_headers beim Apache noch "etag",
der aktualisiert sofort, wenn sich die Datei ändert

@tbt
ok, das ist mal eine Antwort. Muss ich mal testen ob ich das hinbekomme. Die normalen Seiten haben alle schon einen ETag, bei den Bilder weiß ich es nun gar nicht genau.

Hm, also habe das jetzt mal getestet. mod_header war gar nicht aktiv. Habe es nun mal aktiviert und eine Test-Header-Zeile einfügen lassen. Die ist da, funktioniert also.

Aber das mit dem ETag geht nicht. Weder mit der Schreibweise von Dir noch mit der aus dem Apache-Handbuch. Der ETag bleibt der gleiche, auch wenn zwischenzeitlich das Bild schon mehrfach ausgetauscht wurde. Andere Größe, anderes Datum, gleicher Name.

Das liegt möglicherweise daran, daß die Bilder ALLE schon länger auf Deinem Server-1 liegen und die Benutzer der Bilder nur die Zuordnung ändern.

(1) Probier es mal mit einen wirklich Neuen Bild!
Wenn das klappt solltest Du einfach die Bilder-Galerie die Du zur Verfügung stellst ab und zu (gezielt beim Verändern der Bild-Zuordnungen) mit neueren Datei-Datum versehen (internes Copy mit Datums-Erneuerung).

(2) Andere Variante: Ermittle die durchschnittliche Änderungsrate der Bild-Zuordnungen und reduziere dann das entsprechende Caching von 6 Monaten auf die Hälfte der durchschnittlichen Änderungsrate. Falls diese aber größer als die 6 Monate ist bringt das leider nix. Dann muß die programmtechnisch etwas Aufwändigere Variante (1) her!

also bei mir geht es (in meinem Forum das Logo als Test)


"ls -l" bringt
-rw-r--r-- 1 sven sven 2867 30. Okt 16:13 logo.png
ETag ist: "47728790af100"

touch logo.png
ls -l
-rw-r--r-- 1 sven sven 2867 18. Dez 23:29 logo.png
ETag ist: "47b0844ad3740"

du brauchst in FF den cache nicht loechen - ctrl+f5 laedt alle dateien neu vom server. zu deinem problem: am besten waere es wenn du den dateinamen fortlaufend hast und dann eben dort, wo das bild eingebunden ist ebenfalls aufs neue bild verweisst.

Synonym hat geschrieben:Nachtrag, da eben erst bemerkt:
Ein Bild ist online. Wird im Browser angezeigt. Dann wird das Bild im Kundenbereich geändert. JETZT lösche ich manuell den Cache vom FireFox (Disk cache device -> Number of entries: 0). Ok, der Browser-Cache ist leer. Rufe ich das Bild nun nochmal auf, denn kommt dennoch das alte Abgesehen von meinen oben genannten Problemen, wo kommt da denn nun das alte Bild her?

Du sagtest

zentraller ImageServer
dezentralle SiteServer mit ImageCache

Wo kommt dann wohl das Bild her wenn aufm ImageServer das Bild nicht mehr ist?

@alle
Also jetzt kommt hier etwas Verwirrung rein.

@Stephan Zöllner
Die Bilder liegen teilweise schon länger auf dem Server, aber nicht die die geändert werden. Wenn einer im Kundenbereich ein Bild ändert, dann stellt der Server eine FTP-Verbindung mit dem Server-1 her und lädt die Bilder hoch. Die Dateinamen bleiben denn gleich, aber das Bild an sich, die Dateigröße und auch das Datum der Erstellung und Modifikation ändern sich. Habe es auch insoweit getestet, dass ich mir ein Bild per FTP herunter geladen habe, im Fotoshop bearbeitet und dann wieder hochgeladen. Also mehr Ändern, außer den Dateinamen, geht ja nicht mehr, oder?

@TBT
Ja, sollte eigentlich auch gehen, ist ja der Sinn davon. Bei meinem HTML-Seiten die mit Etag versehen sind geht es ja auch. Bei den Bilder sehe ich aber ein anderes Problem, dazu aber am Ende mehr wenn ich die anderen auch kommentiert habe.

@nerd
Strg-F5 reicht aus, das weiß ich, aber sag das mal den Kunden die ständig anrufen, das ist dann langsam schon nervend. Bei mir war das mit dem Cache-Löschen ja auch nur ein Test, aber selbst da hat der FF immer noch das alte Bild geladen, eben bis ich Strg-F5 drückte, aber das ist ein anderes Thema und auch nur bei mir im FF so, die anderen Browser nicht.

@800XE
Jep, ein Server (Server-1) auf dem alle Dateien liegen. 99,9% davon Bilder, der Rest PDF. Aber jetzt verstehe ich Deine Frage nicht mehr. Der "ImageCache", also das bisherige "Expires" ist auf dem Server-1. Wenn das Bild dort gelöscht wird, dann ist es gelöscht und kommt von nirgends mehr, eventuell ist es noch im BrowserCache, aber genau das soll ja nicht sein.

@TBT, Nerd
Also so wie ich mir das heute Nacht überlegt habe kann das mit dem ETag ja bei mir nicht funktionieren. Der Sinn dabei ist ja, dass der Browser eine Anfrage an den Server sendet mit dem ETag. Der den dann vergleicht und entweder ein 304 liefert oder eben die neue Datei. Da ich aber, wie im ersten Post beschrieben, mit Expires +6 Monate arbeite, stellt der Browser ja gar keine Anfrage an den Server. Also wird das Bild auch nicht mit 200 oder 304 beantwortet. Hört sich irgendwie logisch an und scheint wohl auch das Problem zu sein.

Zwei Lösungen die ich da sehe, aber nicht weiß ob die auch funktionieren.

1. Expires verwenden und Bildernamen immer ändern
Dann kann der Browsercache die Bilder so lange speichern wie er mag und wenn das Bild geändert wurde, dann hat es einen neuen Namen. Nachteil: -> direkte Verlinkungen gehen dann nicht und mein eigener Dateicache für die HTML-Dokumente (MSQL-Entlastung) dann auch nicht.

2. Expires entfernen und nur mit ETag arbeiten, Bildernamen beibehalten
Dann müsste es so funktionieren wie von Dir, TBT, beschrieben. Allerdings werden dann immer Anfragen an den Server gestellt, nämlich ob der ETag noch stimmt oder nicht. HTML-Cache könnte dann auch bleiben, weil die Namen sich ja nicht ändern. Direkte Verlinkungen gehen dann auch weiterhin.

So, nur was ist besser? Alles direkt im Browser-Cache belassen und die Bildnamen neu vergeben, dafür aber keinen HTML-Cache - oder eben für jedes Bild eine Anfrage an den Server und auf 200 / 304 warten, dafür aber die Datenbank entlasten.

Also das mit dem Expires ist mir da eigentlich sympathischer, aber so recht weiß ich nicht....

Andere Portale mit Bildern von Kunden
Flickr: Dynamischer Dateiname, mit Expires, kein ETag
Fewo24: Fester Dateiname, kein Expires, mit ETag

Ich sehe das Problem nicht so ganz. Der Apache sendet bei Dateien von ganz alleine das letzte Änderungsdatum derselben mit (Last-Modified) und jeder Browser sendet von Haus aus eine entsprechende bedingte Anfrage (If-Modified-Since), sofern er das Objekt bereits im Cache hat und der Benutzer nicht so dusselig war, seinen Cache abzuschalten.

Speziell FileETag mtime ist somit überflüssig, a) ist es nur eine andere Methode, die Server-Antwort Not modified zu ermöglichen, b) macht es in dieser Form nur, was per Last-Modified eh schon gemacht wird und c) ist FileETag standardmäßig aktiv, das muss nicht erst eingeschaltet werden.
Wenn man's ganz pingelig nimmt, ist die Option mtime alleine sogar kontraproduktiv, denn Vorgabe ist FileETag INode MTime Size, d.h. mit der vorgeschlagenen Angabe werden fürs ETag weniger Änderungsmerkmale herangezogen als von Haus aus. Selbst FileETag none wäre sinniger, weil dann nicht dieselbe Arbeit doppelt gemacht werden muss.

Ganz grundsätzlich: Du hast keine Möglichkeit, einen Browser vom Server ausgehend über eine Änderung zu informieren, du musst darauf warten, dass der Browser sich beim Server meldet. Anders geht es nicht.

Wenn du Wert darauf legst, dass die Änderungen sofort sichtbar werden, musst du auf jegliche Expires-Angabe verzichten; die Last-Modified-Geschichte bleibt davon unberührt, die ist immer aktiv.
Das Mindestmaß an Datenverkehr, den du unter der Bedingung sofortiger Sichtbarkeit erreichen kannst, bekommst du auf diesem Wege. Weniger wird's nicht, du wirst dann in diesen sauren Apfel beißen müssen. Allerdings ist das gleichzeitig auch das notwendige Maximum, denn mehr Nutzen als sofortige Sichtbarkeit gibt es nicht.

Weniger Verkehr erreichst du nur, wenn du Expires einsetzt - allerdings dann halt mit der Einschränkung, dass Änderungen erst nach einem Zeitraum x sichtbar werden.
Dazu sei angemerkt, dass laut Yahoo der Anteil der Cache-Treffer deutlich geringer ist als man gemeinhin glaubt. Von einem Expires-Zeitraum von 6 Monaten hast du wahrscheinlich keinen Vorteil gegenüber einem Zeitraum von 6 Wochen, möglicherweise sogar gegenüber 6 Tagen. Das Kosten/Nutzen-Verhältnis wird für dich eher besser, je kürzer der Expires-Zeitraum ist. Probiere es doch einfach mit 5 Minuten oder einer halben Stunde. Bei so kurzen Zeiträumen sind Cache-Treffer am wahrscheinlichsten, weil die Zugriffe noch innerhalb des aktuellen Besuchs stattfinden, entsprechend ist der Nutzen für dich besser im Verhältnis zu der Änderungssichtbarkeit.
Welches Verhältnis nun für dich in Frage kommt, musst du entscheiden. Du wirst es aber nicht so hinbekommen, dass ein Bild nur dann angefragt wird, wenn es notwendig ist, weil es geändert wurde. Das ist technisch-logisch nicht möglich.

Hi Mork vom Ork,

also das bestätigt mich bzw. meine Vermutung durchaus.

Habe nun zwei Versuche gemacht. Einmal mit Expires und einmal ohne. Mir persönlich gefällt die Lösung mit besser. Um dann dennoch Änderungen sichtbar werden zu lassen werden nun halt die Bilder mit einmaligen Namen versehen. Den eigenen HTML-Cache stelle ich ab. Dort gab es ja nicht nur die Probleme mit den Bildern, sondern auch mit Änderungen an Texten etc. Dann muss halt meine Datenbank ein wenig mehr arbeiten, aber das wird die schon verkraften - hoffe ich

... dass ein Bild nur dann angefragt wird, wenn es notwendig ist, weil es geändert wurde. Das ist technisch-logisch nicht möglich

Jep, und genau da hatte ich mich verrannt. Im Browser Cachen, Expires setzen und dann gleichzeitig erwarten, dass der Etag verglichen wird... Das ist zu viel des Guten

Bezüglich der Dauer des Expires gebe ich Dir recht. Wenige Stunden oder kürzer würden da ausreichen. So hatte ich es ja bisher -> 30 Minuten. Aber selbst wenn ich da nur auf 5 Minuten gehen würde würde das nichts bringen. Zwischen der Änderung der Bilder und dem Anruf der Kunden (weil es nicht sichtbar ist) liegen in aller Regel nur 1-2 Minuten und dann wird der ganze Cache sinnlos.

Weniger Verkehr erreichst du nur, wenn du Expires einsetzt - allerdings dann halt mit der Einschränkung, dass Änderungen erst nach einem Zeitraum x sichtbar werden.

Oder wenn sich die Dateinamen ändern Also ja eigentlich in der Art:
Bild vom Server abrufen -> im Browser-Cache speichern. Erneuter Zugriff -> Bild aus Browser-Cache.
Bild ändern -> Seite aufrufen -> neues Bild -> vom Server holen -> und wieder in den Browser-Cache.
Dann fragen Browser ja auch trotz Expires zwischendurch die Daten erneut ab (If-Modified-Since). In dem Fall dann ETag vergleichen -> und 304 senden, oder eben das neue Bild.

Hm, hoffe mich da nun nicht wieder verrannt zu haben. So läuft es nämlich jetzt gerade

Danke und Gruß,
Ingo

Synonym hat geschrieben:Server-1: Auf dem sind alle Bilder gespeichert. Diese werden auch mit "Expires + 6 Monate" ausgeliefert, damit diese nicht bei jedem Zugriff neu angefordert werden.

Die Bilder werden auf verschiedenen Domänen verwendet, die diese jeweils vom Server-1 laden. Soweit so gut.

Das klingt nach

Domain4User.tld .... mit imgSrc@himself .... holt sich dann die Bilder von ImageServer.tld und Cacht die Bilder

Synonym hat geschrieben:@800XE
Jep, ein Server (Server-1) auf dem alle Dateien liegen. 99,9% davon Bilder, der Rest PDF. Aber jetzt verstehe ich Deine Frage nicht mehr. Der "ImageCache", also das bisherige "Expires" ist auf dem Server-1. Wenn das Bild dort gelöscht wird, dann ist es gelöscht und kommt von nirgends mehr, eventuell ist es noch im BrowserCache, aber genau das soll ja nicht sein.

Aber ... Domain4User.tld hat dann wohl doch die ImageServerURL im imgSrc .... also kein Cache


ähm ... ne ... jetzt sagtest du ja ....
imgServer schickt die Bilder dann zu Domain4User ....

Dann ist bei Domain4User auch kein Cache sondern ein dezentraler Speicherort und ImageServer ist ..... ach, egal


warum sprichst du von 2 Servern wenn doch nur einer im SPiel ist (bezüglich der Bild Requests)

@800XE
Also entweder ließt sich das so schwer oder ich lese falsch

Bei mir gibt es derzeit 8 Server. 6 davon erledigen nur die eigentlichen Anfragen der Webseite. PHP -> HTML-Auslieferung. Einer ist nur für Datenbank / Mailserver und einer, eben der so genannte Server-1, nur für die Files (fast nur Bilder, ein paar PDF´s)

Den Cache der Bilder übernimmt Server-1. Die anderen Server haben mit den Bildern nichts zu tun, die cachen wenn überhaupt nur die HTML-Dokumente.

Domain4User.tld hat dann wohl doch die ImageServerURL im imgSrc

Genau. Der Aufbau ist immer, egal welche Domain: <img src="Server-1/bilder/kunden/..." />

Äm, je, jetzt weiß ich glaube ich auch was Du meinst.... "die diese jeweils vom Server-1 laden" Die eigentlichen Webseiten / Server holen sich die Bilder nicht vom Server-1, nur der imgsrc zeigt da hin.

Dann ist bei Domain4User auch kein Cache sondern ein dezentraler Speicherort und ImageServer ist ..... ach, egal

Auf der von Dir benannten Domain4User sind keine Bilder und da werden auch keine zwischengespeichert. Wie gesagt, wenn überhaupt, dann nur die dort vorliegenden HTML-Dokumente, mehr nicht. Nur der von Dir als ImageServer genannte Server hat Bilder und nur der liefert sie aus, inkl. allen Etag, Headern, Expires und was noch alles.

warum sprichst du von 2 Servern wenn doch nur einer im SPiel ist (bezüglich der Bild Requests)

Das ist eine gute Frage. Wo habe ich das denn? Oder meinst Du damit das "die diese jeweils vom Server-1 laden". Wenn ja, dann war das so nicht gemeint, bzw. sollte nicht das aussagen.

Gruß, Ingo

du hast aber schon die ETag Angabe auf dem Server-1 gemacht, der auch die Bilder ausliefert, oder?

@TBT
Ja klar, wo denn sonst
Wie schon oben gesagt, so lange da ein Expires gesetzt ist, der noch nicht abgelaufen ist, wird das Bild ja gar nicht neu angefragt, daher kann der "neue" Etag ja auch nicht gesendet werden. Per F5 oder Strg-F5 schon, aber das ist ja nicht der normale Zustand. Jetzt wo die Bilder eindeutige (dynamische) Namen haben funktioniert es, auch mit dem ETag und das ohne die Seite reloaden zu müssen.

Mir ist nur noch eine Sache aufgefallen und die ist wohl auch mit Grund meiner Verwirrung. Früher wurden Dateien die aus dem Browser-Cache kommen im FF (Seiteninformationen) auch so angezeigt bzw. so benannt. Das ist nun nicht der Fall.

Antwort Header Würde für mich eigentlich bedeuten, dass das Bild vom Server geladen wurde und kein Expires gesetzt ist. Fakt ist aber, dass das Bild aus dem Browser-Cache kommt so wie es auch soll. Auf der Console läuft ein tail -f nebenher und da wurde der Request nicht erfasst.

Selbes Bild, dann aber nicht nur aufgerufen, sondern auch mit F5 neu geladen
Das ergibt genau den gleichen Antwort-Header, aber diesmal wurde der Zugriff mitgeloggt und laut Logfile mit 304 beantwortet. Selbes Bild mit Strg+F5 ergibt dann wieder einen eindeutigen Zustand.

Synonym hat geschrieben:Mir persönlich gefällt die Lösung mit Expires besser. Um dann dennoch Änderungen sichtbar werden zu lassen werden nun halt die Bilder mit einmaligen Namen versehen. Den eigenen HTML-Cache stelle ich ab. Dort gab es ja nicht nur die Probleme mit den Bildern, sondern auch mit Änderungen an Texten etc. Dann muss halt meine Datenbank ein wenig mehr arbeiten

Du könntest noch versuchen, den Last-modified-Mechanismus für die HTML-Daten einzubauen.

Weniger Verkehr erreichst du nur, wenn du Expires einsetzt

Oder wenn sich die Dateinamen ändern
[&#8230;]
Dann fragen Browser ja auch trotz Expires zwischendurch die Daten erneut ab (If-Modified-Since).

Nein, solange das Verfallsdatum aus Expires nicht erreicht ist, wird keine neue Abfrage gestartet.

Last-Modified/If-Modified-Since hat per Definition keine Auswirkungen auf Expires. Der Expires-Mechanismus wird lediglich durch die Browser-Einstellungen ausgehebelt (neben dem zwangsweisen Neuladen), dort gibt es in der Regel die Wahl zwischen den Möglichkeiten, nie zu prüfen (sich an Expires zu halten), einmal pro Besuch zu prüfen (IIRC Vorgabe zumindest bei Opera) und immer zu prüfen.

In dem Fall dann ETag vergleichen

Nein, da hast du etwas falsch verstanden. Last-Modified ist auch keine Vorbedingung für ETag, den Änderungsstatus kann der Browser per ETag/If-Match, per Last-Modified/If-Modified-Since oder mit beiden gleichzeitig prüfen.

Welchen Weg der Browser wählt, ist verhältnismäßig wurscht, die Daten sind austauschbar, insbesondere natürlich, wenn ETag nur auf das Änderungsdatum zugreift, welches ja auch Grundlage für Last-Modified ist. Hat der Browser einen ETag-Wert, müsste er zwar laut Protokoll diesen auf jeden Fall zur Prüfung heranziehen, in der Praxis scheint es aber so zu sein, dass stattdessen Last-Modified immer bevorzugt wird. Wenn ich mir Firefox so anschaue, habe ich den Eindruck, die ganze ETagerei ist vergebene Liebesmüh', denn ein If-Match ist mir dort noch nicht aufgefallen, ganz im Gegensatz zu den massenhaft auftauchenden If-Modified-Since. Ich müsste das direkt mal protokollieren &#8230;

Synonym hat geschrieben:Mir ist nur noch eine Sache aufgefallen und die ist wohl auch mit Grund meiner Verwirrung. Früher wurden Dateien die aus dem Browser-Cache kommen im FF (Seiteninformationen) auch so angezeigt bzw. so benannt. Das ist nun nicht der Fall.

Das sieht zwar merkwürdig aus, ich würde dem aber nicht allzu viel Bedeutung beimessen. Wichtig ist, was der Server ausspuckt, denn auf das, was die Browser deiner Besucher daraus machen, hast du letztlich eh keinen Einfluss. Dein Server sendet Last-Modified, ETag und Expires (hier allerdings nicht zu sehen, warum das?) und keine Einschränkung per Cache-Control - mehr kannst du nicht machen.

Mit Firebug lässt sich davon abgesehen das Verhalten des Browsers IMHO besser überwachen. Alternativ kannst du die Serverreaktion natürlich auch per telnet prüfen.