Caching issues

[saerdnaer]

Bekannte Probleme:

• nach Deployment einer neuen Version dauert es mehr als 15 Minuten bis sich Änderungen z.B. am Player durchschlagen, ?foo an die URL anhängen hilft nicht.
• Wenn ein Event angelegt wird, triggert das neu-anlegen eines Recordings keine Cache Refresh und mann muss die 10 Minuten warten und sieht solange die kappute Talk-View.
• tbc…

[manno]

Anhängen von ?foo darf nie das Caching brechen, damit würden wir anonymen Usern einen DOS Angriff schenken.

media.ccc.de benutzt zwei Caches, den nginx cache und das Caching von Rails (redis).

Ich finde 15 Minuten tolerierbar. Meiner Ansicht nach gibt es drei Anwendungsfälle in denen man Änderungen schneller sehen will:

1. während eines Releases/Konferenz
2. Reguläre Updates von voctoweb
3. Fehler

Zu 1. haben wir uns nginx cache breaking angeschaut, um einzelne Seiten zu invalidieren. Leider ist das Modul nur in Nginx Pro enthalten. Vermutlich braucht man mehr als das, um voctoweb von einem 'Video-Archiv' in eine gute Live-Streaming Experience zu wandeln.
Wir haben seit kurzem Relive Support, wenn Konferenzen es unterstützen, sollte der Relive Player statt
einem kaputten Talk View eingeblendet werden.
Für Konferenzen die das nicht unterstützen, würde es vermutlich helfen auf der 'kaputten' Seite hilfreiche Informationen statt leerer Elemente anzuzeigen: Statusmeldung, Links zu alternativen Videos.

Zu 2. finde ich den Aufwand nicht gerechtfertigt. Kein reguläres Update muss so so schnell online gehen? Es kann aber über localhost getestet werden, wo das Caching hängt. Nginx oder Rails.

Ich glaube wir reden so viel über Caching wegen Punkt 3., Fehler in der Anwendung oder in deploytem Code. Leider ist die Testabdeckung nicht so gut (schreibt Integration Tests!:) und die Anwendung zu komplex, um auch. den letzten Feed auf dem Staging System getestet zu haben.

Freizügiges Cache löschen kann dazu führen, dass wir Fehler nicht beseitigen. Zum Beispiel, dass ein Recording keinen Cache Refresh triggert, kann eigentlich nicht sein: https://github.com/voc/voctoweb/blob/master/app/models/recording.rb#L32
Vermutlich gibt es einen View der einen falschen Cache-Key benutzt. Ist die URL bekannt, bei der dieser Fehler aufgetreten ist (gehört vlt. auch in eigenes Issue)?

[saerdnaer]

Damals ist es @a-tze bei https://media.ccc.de/v/35c3chaoswest-29-die-eigene-stimme-hacken aufgefallen: Die ersten 15 Minuten waren dort keine Recordings, obwohl diese bereites angelegt waren.

Ein Fall auf den ich grade gestoßen bin: Bei https://media.ccc.de/v/1110 ist grade noch der HTML Inhalt (mit crossorigin="anonymous" im <video>-Tag), die der Code eigentlich seit >12h nicht mehr produziert.