# 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](/pt-br/documentacao/plataforma/applications/como-funciona/#cache). 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](/pt-br/documentacao/plataforma/applications/limites/#cache-settings). Para saber como um TTL de 0 segundos difere de contornar o cache, consulte [Bypass Cache e um TTL de 0](/pt-br/documentacao/plataforma/applications/application-accelerator/variacao-de-cache/#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=` 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](/pt-br/documentacao/plataforma/applications/cache/cache-settings/#cache). --- ## 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: ```text httpsstatic.example.com/media/file.mp4@@bytes=0-1048575 httpsstatic.example.com/media/file.mp4@@bytes=1048576-2097151 ``` 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](/pt-br/documentacao/plataforma/applications/cache/real-time-purge/#tipos-de-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](/pt-br/documentacao/plataforma/applications/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](/pt-br/documentacao/plataforma/applications/cache/cache-keys/#variacoes). Para os controles que ativam uma variação, consulte [Configurações do Application Accelerator](/pt-br/documentacao/plataforma/applications/application-accelerator/configuracoes/#cache-variation). --- ## Tiered Cache [Tiered Cache](/pt-br/documentacao/plataforma/applications/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](/pt-br/documentacao/plataforma/applications/limites/#cache-settings). 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](/pt-br/documentacao/plataforma/applications/cache/real-time-purge/#camadas). --- ## 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](/pt-br/documentacao/plataforma/applications/cache/real-time-purge/). Para os passos, consulte [Purgue conteúdo em cache](/pt-br/documentacao/guias/performance-e-confiabilidade/cache-e-purge/purgar-conteudo-em-cache/). --- ## Recursos relacionados - [Cache settings](/pt-br/documentacao/plataforma/applications/cache/cache-settings.md): Cada campo de um cache setting, com o seu padrão em cada interface. - [Cache keys](/pt-br/documentacao/plataforma/applications/cache/cache-keys.md): O formato completo da key, os headers de debug e cada status de cache nomeado nesta página. - [Tiered Cache](/pt-br/documentacao/plataforma/applications/cache/tiered-cache.md): A segunda camada de cache, as suas topologias e a ordem de purge que ela exige. - [Purgue conteúdo em cache](/pt-br/documentacao/guias/performance-e-confiabilidade/cache-e-purge/purgar-conteudo-em-cache.md): Os passos para remover uma cópia armazenada antes do fim do seu TTL.