Expiração e atualização

Por quanto tempo uma cópia em cache responde no lugar da origem decide quão atualizada é uma resposta e com que frequência a origem é consultada. Em uma aplicação, um cache setting decide esse tempo e o que acontece depois dele, e um purge encerra uma cópia antes do prazo. Como uma requisição chega a uma cópia em cache, com o diagrama do caminho do cache, está em Como Applications funciona.

As seções cobrem TTL e expiração, stale cache, Large File Optimization, cache keys e variações, Tiered Cache e purge.

TTL e expiração

Um cache setting carrega dois TTLs. O TTL de browser controla por quanto tempo o browser de um visitante mantém a sua cópia, e o TTL de cache controla por quanto tempo a Azion mantém a dela. Uma requisição que o browser responde pela sua cópia nunca chega à Azion, e uma requisição que a Azion responde pela cópia dela nunca chega à origem.

De onde vem cada TTL depende do comportamento que o setting seleciona. Na seção Cache, Honor cache policies mantém os headers Cache-Control e Expires que a origem envia e os repassa ao browser, então a origem decide por quanto tempo o seu conteúdo vive. Override cache behavior substitui esses headers, para o cache da Azion, pelo valor de Max Age. A seção Browser Cache carrega a sua própria escolha para a cópia do browser: Honor cache policies, Override cache settings ou No cache. Quando a origem não envia TTL sob Honor cache policies, a Azion mantém a cópia por um TTL padrão.

A cópia expira quando o TTL de cache termina, e a requisição seguinte pelo objeto vai à origem. Quando a origem retorna o objeto, essa resposta atualiza a cópia, e a resposta informa EXPIRED. Uma verificação com headers condicionais também pode encontrar a cópia inalterada. A resposta então informa REVALIDATED, e a origem não transmite o objeto de novo.

O TTL é uma troca entre a carga na origem e a idade do que um visitante vê. Um TTL longo responde mais requisições pela cópia e chega menos à origem, mas o conteúdo que a origem já alterou permanece na cópia até ela expirar. Um TTL curto mantém a cópia próxima da versão da origem, ao preço de mais buscas na origem. Por exemplo, uma aplicação pode ter dois cache settings, cada um aplicado pela sua própria regra. Imagens que raramente mudam recebem um TTL de um dia, e uma listagem que muda ao longo do dia recebe um TTL de alguns minutos.

Max Age tem um piso e um teto. Sem Application Accelerator, o piso é de 60 segundos, e Application Accelerator o reduz. Para cada limite de TTL, consulte Limites de Applications. Para saber como um TTL de 0 segundos difere de contornar o cache, consulte Bypass Cache e um TTL de 0.

Stale cache

Uma cópia além do seu TTL ainda tem utilidade. Com Stale cache ativo no cache setting, a Azion pode reutilizar uma cópia expirada quando uma tentativa de revalidação falha por um de quatro motivos:

• A origem retorna um erro 5xx.
• A conexão excede o tempo limite, ou a origem está inacessível.
• Os headers de cache-control da origem são inválidos ou estão ausentes.
• O objeto está em atualização, com uma revalidação em andamento.

O tempo durante o qual a cópia expirada pode ser entregue é a janela de stale. Sob Honor cache policies, a janela é o valor da diretiva stale-while-revalidate=<ttl> que a origem fornece. Sob Override cache behavior, ou quando a origem omite a diretiva, a janela é de 300 segundos. Durante a janela, o data center entrega a cópia expirada de imediato e busca uma versão atualizada em segundo plano. Quando o novo objeto é armazenado, as requisições seguintes recebem o conteúdo atualizado.

A resposta diz qual caso se aplica. Uma resposta entregue a partir de uma cópia expirada porque a origem não respondeu informa STALE. Uma resposta entregue enquanto a versão atualizada está a caminho, vinda da origem, informa UPDATING.

Stale cache mostra aos visitantes uma página antiga em vez de uma página de erro durante uma indisponibilidade da origem, pelo tempo que a janela durar. O custo é a atualidade: um visitante dentro da janela pode receber conteúdo que a origem já substituiu. Uma alteração que cada visitante precisa ver de imediato é, portanto, um caso para um purge, e não para a expiração.

Se um setting novo começa com o toggle ativo depende da interface. Um setting criado pela API ou pela CLI tem stale cache desativado, e Azion Console o ativa em um setting novo. Para o campo, consulte Cache settings.

Large File Optimization

Um objeto grande pode ser armazenado em cache em fragmentos, e não como uma peça única. Com Large file optimization ativo no cache setting, a Azion divide o arquivo em fragmentos de 1.024 kB. Cada fragmento é entregue conforme o usuário o consome e é armazenado em cache sob demanda, no momento em que é requisitado. A cache key de um fragmento termina em @@bytes= e no byte range que o fragmento contém, então cada fragmento é um objeto próprio.

Por exemplo, um vídeo de 2.097.151 bytes em https://static.example.com/media/file.mp4 gera dois fragmentos. Eles são armazenados sob estas keys:

Um fragmento só é buscado quando um usuário chega a ele, então um download interrompido no meio deixa os fragmentos seguintes sem busca. Os fragmentos que foram buscados permanecem em cache para a requisição seguinte. A fragmentação se aplica ao cache da Azion e à camada do Tiered Cache quando o setting tem esse toggle ativo.

O custo aparece na hora do purge. Um arquivo se torna muitas keys, então um purge lista a key de cada fragmento ou usa um wildcard que termina o path do arquivo com *. Um purge que remove alguns fragmentos e não outros deixa uma mistura de fragmentos novos e antigos no cache. Para os tipos de purge, consulte Real-Time Purge.

Cache keys e variações

Uma variação é uma segunda cópia de uma URL, armazenada sob uma cache key diferente. Enquanto nenhuma variação está ativa, um path é um objeto armazenado. A Azion monta a key padrão a partir do scheme, do host e do path da requisição. O controle de query string de um cache setting começa em ignore, o que mantém a query string fora da key. Quando algo além do path altera a resposta, o cache setting o nomeia, e a key carrega um marcador para ele.

Quatro entradas podem variar uma cópia pela seção Application Accelerator de um cache setting: um argumento de query string, um cookie, o device group em que a requisição se encaixa e o método da requisição. Outras duas vêm de outros lugares. Image Processor acrescenta o formato da imagem quando converte uma imagem, e Large File Optimization acrescenta o byte range de cada fragmento. Cada valor distinto é uma key separada, então cada um é armazenado e purgado separadamente.

Os device groups vêm da aba Device Groups da aplicação, que Device Groups documenta. Com Cache vary by Devices, um setting entrega uma única versão independentemente do dispositivo, ou mantém uma cópia para cada grupo que nomeia.

O método também é uma variação. Respostas GET e HEAD são armazenadas em cache nativamente, e respostas POST e OPTIONS só são armazenadas em cache com Application Accelerator ativo. O corpo da requisição então passa a fazer parte da key como um hash MD5, então dois corpos diferentes enviados a um path são dois objetos.

Uma variação divide as requisições por uma URL entre várias cópias. Menos requisições encontram uma cópia já presente, e um purge precisa alcançar cada cópia. Por exemplo, uma página de listagem que varia por um argumento page armazena uma cópia por número de página, e um purge da listagem precisa nomear cada uma delas. Para o marcador que cada variação acrescenta, consulte Cache keys. Para os controles que ativam uma variação, consulte Configurações do Application Accelerator.

Tiered Cache

Tiered Cache adiciona uma segunda camada de cache entre o cache da Azion e a origem. Quando o data center que recebeu uma requisição não tem uma cópia válida, ele consulta a camada do Tiered Cache antes de consultar a origem. Um miss na primeira camada pode, portanto, ainda ser respondido pelo cache, e a segunda camada mantém os objetos por mais tempo que a primeira.

A camada é ativada por cache setting com o toggle Tiered Cache, e todos os planos a incluem. O setting nomeia uma de três topologias, a região que mantém a camada: nearest-region, br-east-1 ou us-east-1. Tiered Cache também exige Override cache behavior, porque a API o recusa sob Honor cache policies com 21001.

A troca é um salto extra e um piso no TTL. Um miss na primeira camada vai até a segunda antes de chegar à origem. Um setting com Tiered Cache ativo também carrega um TTL mínimo, porque a camada se destina a objetos que permanecem em cache por muito tempo. Em troca, menos requisições chegam à origem. Para o mínimo, consulte Limites de Applications.

Uma regra com Bypass Cache afeta o cache da Azion, e não a camada do Tiered Cache. Uma aplicação com cache settings de Tiered Cache ativos continua a armazenar objetos em cache nessa camada pelo TTL mínimo. A camada é purgada por cache key. Quando você purga um objeto mantido nas duas camadas, purgue primeiro a camada do Tiered Cache e depois a camada do Cache. Caso contrário, a primeira camada é reabastecida com conteúdo desatualizado do Tiered Cache. Para as camadas de purge, consulte Real-Time Purge.

Purge

Um purge remove uma cópia armazenada antes do fim do seu TTL. A requisição seguinte pelo objeto não encontra cópia e vai à origem, a resposta informa MISS e a versão que a origem retorna é armazenada. Um purge entra em fila depois que você o confirma, porque o resultado leva tempo para se propagar. Ele aparece no histórico de purges quando termina em toda a infraestrutura da Azion.

Um purge encontra um objeto pela sua cache key, então o tipo de purge importa para um objeto que varia. Um purge por URL converte cada URL em uma cache key sem considerar a variação de conteúdo. Uma cópia que varia por cookie, device group ou formato de imagem, portanto, sobrevive a ele. Um purge por cache key nomeia cada variação, e um purge por wildcard alcança cada key que corresponde a uma expressão com *. As variações por query string são a exceção que um purge por URL alcança. Os argumentos precisam ser enviados na ordem em que foram apresentados, ou em ordem alfabética quando Sort está ativo.

Remover um objeto com o método HTTP DEL em vez de um purge também faz a primeira requisição GET de um usuário ir à origem. A diferença é a rede de proteção. O método impede que a Azion entregue uma cópia desatualizada quando a origem está inacessível, e uma página de erro é entregue no lugar dela. Ele se adequa a três casos:

• O conteúdo saiu da origem e precisa sair do cache também.
• Um conteúdo cujo timestamp não é confiável precisa de uma remoção forçada e de uma atualização posterior.
• Uma página de erro é preferível a uma cópia desatualizada enquanto a origem está inacessível.

Um purge é a ferramenta para uma alteração que não pode esperar o TTL. O seu custo é a busca na origem que reabastece cada key purgada, e quanto mais keys um objeto tem, por variações ou por fragmentos, mais um purge precisa nomear. Para os tipos de purge e os seus argumentos, consulte Real-Time Purge. Para os passos, consulte Purgue conteúdo em cache.

Recursos relacionados