Variação de cache

Quando a resposta de uma URL depende de um cookie, de um dispositivo ou do corpo de uma requisição, o cache precisa distinguir essas requisições. Em uma aplicação, um switch ativa Application Accelerator, e um cache setting então nomeia as entradas que tornam duas requisições diferentes. Como uma variação altera a cache key, com o diagrama correspondente, está em Como Applications funciona.

As seções cobrem o que o switch libera, o que uma variação custa, como os purges alcançam as variações e como Bypass Cache difere de um TTL de 0.

O que Application Accelerator libera

Ativar Application Accelerator libera quatro capacidades que parecem não ter relação entre si até você ver o que elas têm em comum:

• Variação de cache além da URL, por query string, por cookie, por device group e por método de requisição. A funcionalidade se chama Advanced Cache Key.
• Cache de respostas POST e OPTIONS, além das respostas GET e HEAD que uma aplicação armazena em cache nativamente.
• Um Max Age que pode chegar a 0 segundos, menor que o piso de 60 segundos que vale sem ele.
• Mais sete behaviors do Rules Engine e as variáveis ${request_uri} e ${device_group} nos critérios das regras. Os behaviors são Add Cookie, Bypass Cache, Capture Match Groups, Filter Request Cookie, Forward Cookies, Rewrite Request e Run Function.

O que as quatro têm em comum é o conteúdo dinâmico. A variação de cache dá à cache key a entrada extra de que ela precisa para distinguir duas respostas corretas. O cache de POST e OPTIONS traz os métodos que carregam essa entrada no corpo da requisição. Um TTL menor que um minuto serve ao conteúdo que deixa de ser correto antes de um minuto passar. Vários dos behaviors liberados agem justamente sobre os cookies e os paths que carregam a diferença.

O switch entrega as quatro capacidades ou nenhuma. Uma aplicação não recebe a variação de cache sem receber também os métodos e os behaviors extras. Um cache setting que define uma variação em uma aplicação com o switch desativado é recusado com 21013.

Ativar o switch também não altera nenhum tráfego por si só. Os controles de query string, de cookie e de dispositivo de um cache setting começam em ignore, e a lista de métodos começa vazia. Um cache setting só alcança uma requisição quando um behavior Set Cache Policy o aplica.

Ativar um Produto pode gerar custos relacionados ao uso. Para mais informações, consulte Preços.

O custo de uma variação

A variação de cache tem um custo, e ele decorre de como a key é montada: cada valor distinto de um atributo que varia produz um objeto em cache separado. Isso torna a escolha do atributo pelo qual variar mais consequente do que a decisão de variar. Um cookie cujo valor é único para cada visitante dá a cada visitante uma cópia do objeto. O cache ainda funciona, mas deixa de servir uma resposta armazenada para muitas requisições, e o número de objetos cresce com a audiência, e não com o conteúdo.

Uma allowlist é o controle desse custo. O behavior allowlist nomeia os argumentos de query string ou os cookies que alteram a resposta, então um atributo que ninguém nomeou não pode criar outro objeto. O behavior all varia por todo atributo que chega, inclusive os que a aplicação ignora. Por exemplo, um link que chega com um argumento de campanha ganha o próprio objeto em cache sob all. Sob uma allowlist que não nomeia esse argumento, o mesmo link aponta para o objeto compartilhado.

A ordenação aplica a mesma economia à ordem dos argumentos. Os argumentos escolhidos entram na key na ordem em que a requisição os enviou, então ?a=1&b=2 e ?b=2&a=1 são dois objetos que guardam uma única resposta. Com Sort ativo, essas variações se agrupam sob uma única key, em ordem alfabética. Por exemplo, uma listagem de produtos que muda com os argumentos category e page nomeia os dois em uma allowlist. Com Sort ativo, toda ordem dos dois argumentos chega a um único objeto. O custo da ordenação é que a key deixa de corresponder à URL como o cliente a escreveu, o que importa na hora do purge. Para os passos no Console que definem esses controles, consulte Configure a Advanced Cache Key para uma aplicação.

Variação de cache e purges

Um purge remove um objeto do cache e encontra esse objeto pela sua cache key. Um purge por URL converte a URL que recebe em uma cache key sem considerar a variação de conteúdo. Toda variação que a URL não carrega, portanto, sobrevive a ele. As variações por cookie e as variações por device group não expiram com um purge por URL, e as cópias delas permanecem no cache.

Dois tipos de purge alcançam essas cópias. Um purge por cache key nomeia cada variação, e um purge por wildcard termina a key com @@*. As variações por query string são a exceção, porque a query string faz parte da URL. Um purge por URL alcança essas variações quando os argumentos são enviados na ordem em que foram apresentados, ou em ordem alfabética quando Sort está ativo.

As variações que você configura são também os objetos que um purge precisa alcançar. Uma variação com muitos valores distintos custa, portanto, tanto na hora do purge quanto em armazenamento. Para os tipos de purge e os passos para executar cada um, consulte Real-Time Purge.

Bypass Cache e um TTL de 0

Sem Application Accelerator, o Max Age mais curto que uma aplicação aceita é de 60 segundos, e a API recusa um valor menor com 21021. Application Accelerator remove esse piso e permite 0 segundos, ou 3 segundos quando o cache setting também tem Tiered Cache ativo. Um TTL de 0 não é o mesmo que não armazenar em cache, e a diferença entre os dois é a razão de ambos existirem. Os dois precisam de Application Accelerator, porque Bypass Cache é um dos behaviors que ele libera.

O behavior Bypass Cache envia à origem cada requisição HTTP e HTTPS que corresponde à sua regra, e a Azion não armazena nada no próprio cache. Ele mantém as otimizações de protocolo e, quando possível, uma conexão keep-alive com a origem. Ele não altera o browser cache, que um behavior Set Cache Policy define. Ele também não alcança 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. Use-o quando cada requisição precisa receber conteúdo diferente.

Um Max Age de 0 segundos mantém a requisição no caminho do cache. Requisições paralelas pelo mesmo objeto chegam à origem como uma única requisição, e a Azion valida o objeto com uma requisição If-Modified-Since. Um objeto que não mudou não é transferido de novo, e a resposta pode ser um 304 Not Modified. Um Max Age de 0 ainda cria um objeto em cache, que vive por 999 milissegundos. Use-o quando o conteúdo dinâmico pode ser entregue de forma idêntica a todos que o requisitam no mesmo momento.

A troca é entre a atualidade de cada requisição e a carga na origem. Bypass Cache dá a cada requisição a sua própria resposta, e abre mão tanto da requisição única à origem para requisições paralelas quanto da revalidação que evita a transferência de um objeto inalterado. Um TTL de 0 mantém as duas coisas, e abre mão da capacidade de responder de forma diferente a duas requisições simultâneas.

Recursos relacionados