Varnish não funciona com a última modificação

Question

Sou novo em Varnish e reverter proxies em geral. Estou testando o Verniz em um aplicativo que funciona como um blog no qual tenho uma página com um "updated_at" que muda quando a página é atualizada. Como consequência, decidi que minha estratégia de cache deveria se basear no cabeçalho da última modificação. A razão para isso é que o usuário quer ver a mudança imediatamente depois que a página é modificada no backoffice.

Além disso, eu entendi que eu poderia adicionar um s-maxage com must-revalidate ao cache-control, então se a última modificação não mudasse, o Varnish não tentaria fazer um novo pedido.

Também adicionei uma expiração para o navegador para que haja um cache do cliente. Como resultado, o navegador nem vai pedir ao verniz para fazer um pedido ao Apache novamente.

No entanto, notei que o s-maxage do controle de cache tem prioridade sobre o último-modificado mesmo com revalidação obrigatória. Além disso, mesmo se eu não adicionar um controle de cache, 'last-modified' não funciona. O verniz usa seu padrão ttl e nada acontece. O que estou fazendo errado?

Estou usando o Symfony e esses são os cabeçalhos:

$response = new Response();
$response->setPublic();

// expiration model for the browser cache (EXPIRE)
// the browser will only make a new request to Varnish again after ten minutes (600 seconds)
$date = new \DateTime();
$date->modify('+600 seconds');
$response->setExpires($date);

// expiration model for Varnish (CACHE-CONTROL)
// Varnish will only make a new request to Apache again after one hour (3600 seconds)
// The must-revalidate tells Varnish to do this request before serving the files after one hour (it's already de default behaviour)
// cache-control has priority over expire
//$response->setSharedMaxAge(3600);
$response->headers->addCacheControlDirective('must-revalidate', true);

// validation model for varnish (LAST-MODIFIED)
// Varnish will only make a new request to Apache again if the updated_at of the page changed even if the expiration time is ended
$response->setLastModified($page->getUpdatedAt());

// if the response didn't change, stop here
if ($response->isNotModified($request)) {
    return $response;
}

Aqui estão os meus cabeçalhos da primeira vez quando eu tenho uma MISS e a segunda vez que eu tenho um HIT. Então, não importa se as alterações da última modificação dos cabeçalhos são sempre as mesmas que esta segunda. (Meu navegador cacher está desativado, então tenho 200 em vez de 304)

primeiro pedido

segundo pedido

    

Answer 1

Não existe algo como "Última modificação não funciona". Este cabeçalho indica simplesmente que o recurso de data foi modificado pela última vez. Os clientes podem emitir solicitações "se não modificadas desde" posteriormente, mas isso não é importante para sua situação.

É natural que os pedidos subsequentes retornem exatamente os mesmos cabeçalhos. Objetos em verniz são armazenados em cache, incluindo as informações de cabeçalhos. Então, quando o Varnish extrai uma entrada em cache, ela retornará uma cópia exata dela.

Entendendo

Você está lidando com dois caches ao mesmo tempo: Varnish e cache do navegador. Você tem apenas um conjunto de cabeçalhos HTTP por solicitação. Você não pode especificar um HTTP Expires para o navegador e depois outro apenas para o verniz.

Portanto, se você quiser colocar as coisas em cache de maneira diferente (e você faz), uma solução é ajustar beresp.ttl no verniz para a quantidade de tempo durante o qual você deseja relaxar o backend do PHP, ou seja, 24 horas.

Em algum lugar na VCL:

sub vcl_backend_response {
    # A TTL of 24h
    # set beresp.ttl = 24h;
}

Então, considerando que você mantém seu código PHP existente, o Varnish armazena em cache a primeira requisição para uma página por 24 horas e faz com que seja armazenada em cache pelos navegadores por 10 minutos.

Quando o artigo for atualizado, você terá que limpar o cache de verniz, também conhecido como Invalidação de cache. Veja algumas dicas sobre esta página (role até o final).

The reason for that is the user wants to see the change immediately once the page is modified in the backoffice.

E ainda assim você quer que eles tenham 10 minutos de cache do navegador:)