[PHP/HTTP] Http Cache + Reverse Proxy

[Barryvdh]

Hallo allen,

Niet zozeer een concrete vraag, maar ik was benieuwd hoe jullie website cachen (en invalideren)

Om de reactietijd te vergroten in een Laravel applicatie, wil ik een Reverse proxy gebruiken. Ik gebruik nu Symfony HttpCache, die later makkelijk om te zetten zou moeten zijn naar Varnish oid (omdat hij gewoon de Http cache specificatie gebruikt). Daarnaast wil ik client side laten cachen, zodat de pagina niet steeds opnieuw opgevraagd hoeft te worden (bij wat rondklikken, bespaart tijd/resources).

Nu stel ik bijvoorbeeld in Symfony HttpCache in voor bepaalde pagina's:

PHP:

$response->setPublic();
$response->setMaxAge(300);
$response->setSharedMaxAge(86400);

Dan zou de pagina dus 5 minuten aan de clientside gecached moeten worden, en 1 dag door de reverse proxy. Aangezien de content niet regelmatig veranderd, wis ik nu de cache zodra er een iets veranderd. (Dus dat zou ook een jaar kunnen zijn)

Nu werkt dit opzich prima, de eerste keer komt er een verse reactie, die daarna gecached wordt. De 2de keer wordt voor die gebruiker de server niet meer gebruikt (want in client cache). Nu komt 5 minuten later een andere gebruiker. Deze krijgt de reactie vanuit de reverse proxy, maar omdat deze al > 5 minuten oud is, wordt deze niet meer client-side gecached. Dit is aan de ene kant logisch, maar ik wil eigenlijk dat de client hem ook nog 5 minuten cached. Ligt dat aan HttpCache van Symfony, of is de specificatie gewoon zo? Als ik bijvoorbeeld bij Tweakers kijk, komt de reactie zo te zien uit Varnish, maar is de Age wel altijd 0. (Alleen wordt daar geen client-side caching gebruikt)

Ik heb ook het idee dat de hele cache wissen eigenlijk niet de oplossing is, maar voor relatief kleine sites die weinig veranderen, wel het makkelijkste is. Wat doen jullie om de reverse proxy cache te invalideren? Korte tijden gebruiken, een lijst met urls bijhouden om een PURGE commando te sturen, alleen e-tags/last modified gebruiken?
E-tag/last-modified wou ik eigenlijk niet gebruiken omdat ik het simpel wil houden (gewoon aantal URL's voor bepaalde tijd cachen), aangezien ik anders alsnog per request in de database moet controleren of de inhoud wel/niet gewijzigd is.

(En ja, voor kleine sites is het waarschijnlijk overkill, maar ik wil graag mijn websites zoveel mogelijk optimaliseren voor de gebruiker en voorbereid zijn op een grote toestroom van bezoekers ineens)

[Bigs]

Wij geven vanuit Varnish altijd no-cache,must revalidate mee mee voor dynamische content; simpelweg omdat Varnish ontzettend snel is en het gedoe met client cache scheelt. Vanuit de applicatie purgen we de Varnish cache op het moment dat er iets gewijzigd wordt, dus zo zijn clients ondanks de cache altijd up-to-date.

Alle assets (css, javascript, afbeeldingen) hebben een hash in de bestandsnaam staan die bij elke versie verandert, dus daar haalt de client automatisch de nieuwste versie van op. Die assets laten we dus wel cachen door de client.

[ Voor 16% gewijzigd door Bigs op 10-12-2013 14:01 ]

[Barryvdh]

Bigs schreef op dinsdag 10 december 2013 @ 14:00:
Wij geven vanuit Varnish altijd no-cache,must revalidate mee mee voor dynamische content; simpelweg omdat Varnish ontzettend snel is en het gedoe met client cache scheelt. Vanuit de applicatie purgen we de Varnish cache op het moment dat er iets gewijzigd wordt, dus zo zijn clients ondanks de cache altijd up-to-date.

Alle assets (css, javascript, afbeeldingen) hebben een hash in de bestandsnaam staan die bij elke versie verandert, dus daar haalt de client automatisch de nieuwste versie van op. Die assets laten we dus wel cachen door de client.

Maar dan purge je dus gewoon de hele cache in 1 keer, of specifieke pagina's?
Assets ed. geef ik inderdaad ook een hash mee + 1 jaar client cache.
Symfony HttpCache is wel snel, maar moet nog steeds een deel van het framework laden (in mijn geval Laravel) en clientside cache is dus toch een stuk sneller.

[Cartman!]

Voor dynamische content tussen statische content in kun je gebruik maken van Esi waarin je bepaalde delen wel lange tijd cacht. Of gewoon alles statisch maken en via XHR de dynamische userinfo laden.

Voor kleine sites klinkt het echt als overkill, ga niet iets al compleet cachebaar maken voor iets voor 10 bezoekers per dag. Tegen de tijd dat het storm gaat lopen kom je waarschijnlijk snel meer problemen tegen dan cache alleen waardoor je bestaande code base al refactoring moet ondergaan.

[Bigs]

Barryvdh schreef op dinsdag 10 december 2013 @ 14:06:
[...]

Maar dan purge je dus gewoon de hele cache in 1 keer, of specifieke pagina's?
Assets ed. geef ik inderdaad ook een hash mee + 1 jaar client cache.
Symfony HttpCache is wel snel, maar moet nog steeds een deel van het framework laden (in mijn geval Laravel) en clientside cache is dus toch een stuk sneller.

Ik heb het volgende stuk je code in m'n VCL:

code:

if (req.request == "BAN") {
  ban("req.url ~ "+req.url+" && req.http.host == "+req.http.host);
  error 200 "Banned.";
}

Dan kun je dus heel simpel een request sturen met een regex erin:

code:

BAN /secties/foo/.*
Host: bar.nl

Dat gooit alle pagina's onder /secties/foo/ uit de cache.

[ Voor 3% gewijzigd door Bigs op 10-12-2013 14:27 ]

[Barryvdh]

Cartman! schreef op dinsdag 10 december 2013 @ 14:23:
Voor dynamische content tussen statische content in kun je gebruik maken van Esi waarin je bepaalde delen wel lange tijd cacht. Of gewoon alles statisch maken en via XHR de dynamische userinfo laden.

Voor kleine sites klinkt het echt als overkill, ga niet iets al compleet cachebaar maken voor iets voor 10 bezoekers per dag. Tegen de tijd dat het storm gaat lopen kom je waarschijnlijk snel meer problemen tegen dan cache alleen waardoor je bestaande code base al refactoring moet ondergaan.

Klopt, maar het gaat in de eerste instantie dus ook niet om dynamische pagina's, alleen de anonieme pagina's waar af en toe nieuwsberichten/blogs/andere content op geplaatst wordt. Vandaar dat ik het ook zo simpel mogelijk wil houden, maar vooral gewoon snelle reactietijd en minder resources verbruiken.