Edge Cache

Edge Cache é um módulo disponível para Edge Application que permite que você configure como sua aplicação faz o cache de conteúdo, reduzindo a latência e aumentando a taxa de transferência através da edge network da Azion. Isso não apenas melhora o desempenho e a escalabilidade do seu conteúdo, mas também reduz os custos de infraestrutura.

Na Azion, você pode personalizar o tempo que o cache permanece no edge através dos valores de time-to-live (TTL). Políticas de cache com valores maiores de TTL podem otimizar o desempenho de sua aplicação, melhorando a experiência de seus usuários e reduzindo o tráfego com a origem. No entanto, um TTL de cache baixo pode ajudá-lo a garantir que os usuários finais sempre vejam as informações mais atuais.

Se os servidores de origem estiverem inativos ou ficarem indisponíveis, o Edge Cache da Azion também pode servir conteúdo do cache para seus usuários a partir do edge.

EscopoRecursos
Configurações de cache disponíveisCache Settings
Módulo Tiered CacheTiered Cache
Configurar uma política de cacheComo configurar políticas de cache para Edge Application

A Azion fornece uma camada para armazenar conteúdo em cache na edge network, que atua entre os servidores de origem e o usuário final. Quando o conteúdo é armazenado em cache, ele recebe o cache status HIT e pode ser entregue diretamente aos seus usuários a partir do edge node mais próximo a eles, reduzindo a frequência de acesso aos seus servidores de origem.

Quando o conteúdo requisitado não está disponível em cache, o módulo Edge Cache da Azion emprega estratégias para minimizar o impacto no servidor de origem e otimizar a entrega de conteúdo. Uma dessas estratégias inclui manter conexões keep-alive com o servidor de origem sempre que possível, para reduzir a sobrecarga associada a handshakes TCP/IP frequentes. Isso é eficaz durante atualizações de cache ou em situações de um cache MISS.

Além disso, a Azion implementa o controle de Thundering Herd para garantir que, diante de múltiplas requisições simultâneas para o mesmo objeto não armazenado em cache, apenas uma conexão seja estabelecida com o servidor de origem. Essa abordagem garante que cada um dos edge nodes da Azion solicite conteúdo ao servidor de origem apenas uma vez por MISS ou outros status não-HIT, otimizando, assim, a eficiência da rede e reduzindo a carga no servidor de origem.

Você pode obter o status de qualquer recurso em cache em uma edge application por meio de uma requisição para a URI do conteúdo, adicionando o cabeçalho de debug da Azion Pragma: azion-debug-cache. Uma resposta bem-sucedida retornará um cabeçalho X-Cache com o status do cache, o IP do edge node de qual foi retirado e o protocolo utilizado:

Terminal window
X-Cache: HIT from 200.000.000.00 with HTTP/2.0
StatusDefinição
HITConteúdo válido e atualizado é fornecido diretamente do cache do edge
MISSSe o conteúdo da requisição não for encontrado no cache no edge, ele é buscado na origem. Por meio da resposta, o conteúdo pode ser armazenado em cache no edge para futuras requisições
EXPIREDO conteúdo em cache expirou o TTL definido no edge. Quando a origem responde, o conteúdo em cache é atualizado para futuras requisições
STALEAo optar por servir stale cache, se a origem falhar em responder e o cache edge expirou, uma versão obsoleta do conteúdo é servida
UPDATINGO conteúdo em cache expirou e o stale cache está sendo servido, mas o conteúdo será atualizado para futuras requisições
REVALIDATEDO conteúdo em cache é verificado contra o da origem usando cabeçalhos condicionais. Se ainda estiver atualizado, o recurso não é retransmitido pela origem
BYPASSO edge solicita o conteúdo diretamente da origem em vez de usar uma versão em cache devido ao comportamento Bypass Cache
-Se nenhum status for recebido, o conteúdo do request está restrito de permanecer em cache. Por exemplo, se o conteúdo é uma requisição POST e Caching for POST está desabilitado, o status não é recebido

Uma cache key é uma entrada de índice para um objeto nos edge nodes da Azion. Quando uma requisição é feita para uma edge application pela primeira vez, o edge encaminha a requisição para o servidor de origem e gera um cache para cada objeto recebido. Quando a próxima requisição do mesmo recurso é feita para a edge application, se o recurso solicitado corresponder a um já encontrado por meio da cache key, a requisição não será encaminhada para a origem.

Você pode obter a cache key de qualquer recurso em uma edge application por meio de uma requisição para a URI do conteúdo, adicionando o cabeçalho de debug da Azion Pragma: azion-debug-cache. Uma resposta bem-sucedida retornará um cabeçalho X-Cache-Key com o valor da cache key:

X-Cache-Key: httpsseudominio.com/caminho-do-recurso/imagem.jpeg@@

O formato padrão da cache key adotado pela Azion concatena os seguintes elementos de sintaxe da URI:

  • Schema da requisição
  • Host
  • Path do recurso
  • Query strings
  • Um separador de variação e, quando implementadas, variações

Um objeto com a URI https://static.seudominio.com/pagina/site.js deveria gerar a cache key httpsstatic.seudominio.com/pagina/site.js.

Cache keys são case-sensitive, o que significa que caracteres em maiúsculo e minúsculo são reconhecidos como distintos.

Algumas cache keys também podem mudar dependendo de variações geradas no edge. Usando o exemplo anterior, se variações forem habilitadas, a cache key poderá conter o marcador @@ no final, resultando em httpsstatic.seudominio.com/pagina/site.js@@.

Se o recurso é obtido usando uma requisição complexa (qualquer método diferente de GET ou HEAD), o método é adicionado no início da cache key.

Por exemplo, para uma requisição OPTIONS, a cache key gerada para um objeto seria optionshttpsstatic.seudominio.com/pagina.

Quando o Image Processor está ativado, além da query string ims, variações com formato convertido contêm o formato do arquivo após o separador.

Por exemplo, para uma imagem redimensionada e convertida no formato webp, a cache key gerada será httpsstatic.seudominio.com/static/imagens/imagem_1.jpg?ims=880x@@webp.

Se houver uma variação de objetos por device groups, o separador @@ e o nome do device group serão acrescentados ao final.

Por exemplo, para uma aplicação que implementa variação pelo grupo Mobile, a cache key gerada será httpwww.seudominio.com/@@Mobile.

Quando a funcionalidade Advanced Cache Key estiver configurada, a formação das cache keys também é afetada.

Cache by Cookie gera uma variação de cache key com os nomes e valores do cookie determinados seguidos por ;.

Por exemplo, a variação de conteúdo com base no cookie usuário poderia gerar as seguintes cache keys:

  • httpwww.seudominio.com/@@;
  • httpwww.seudominio.com/@@user=usuario;

Cache by Query String gera cache keys com o separador de consulta e os argumentos determinados com base na ordem das strings de consulta submetidas na requisição.

Por exemplo, a variação de conteúdo com base em nome e cidade poderia gerar as seguintes cache keys:

  • httpstatic.seudominio.com/pagina?name=nome
  • httpstatic.seudominio.com/pagina?city=cidade&name=nome
  • httpstatic.seudominio.com/pagina?name=nome&city=cidade

Para várias query strings, se Query string sort estiver ativado, as strings de consulta serão agrupadas sob a mesma cache key, ordenadas alfabeticamente.

Para fragmentação de arquivos, a cache key acrescenta o separador @@bytes= para cada fragmento de conteúdo.

Por exemplo, para um arquivo de 2097151 bytes de tamanho, se Large File Optimization estiver ativado, as cache geradas serão:

  • httpstatic.seudominio.com/midia/arquivo.mp4@@bytes=0-1048575
  • httpstatic.seudominio.com/midia/arquivo.mp4@@bytes=1048576-2097151

Para solicitações POST ou OPTIONS em cache com corpo, a cache key acrescenta o separador @@ seguido pelo hash MD5 do corpo da requisição.

Por exemplo:

  • httpsdynamic.seudominio.com/caminho@@md5_dos_argumentos_post
  • httpsdynamic.seudominio.com/caminho@@md5_dos_argumentos_options

Com o Edge Cache, você pode personalizar o TTL (Time-to-Live) de cache do navegador e do edge de acordo com seus requisitos específicos.

Ao definir seu TTL para o cache do navegador, você pode controlar por quanto tempo o conteúdo permanece armazenado nos navegadores locais. Um valor maior de TTL pode reduzir a necessidade de seus usuários buscarem conteúdo dos edge nodes ou da origem, melhorando os tempos de carregamento.

Você também pode definir por quanto tempo seu conteúdo deve permanecer em cache nos edge nodes da Azion. Um TTL de CDN cache mais longo pode melhorar o desempenho de entrega de conteúdo. Sendo acessado com frequência, o conteúdo permanece disponível mais perto dos usuários, reduzindo a carga no servidor da origem.

Encontrar o equilíbrio certo para os tempos de expiração de cache é crucial para garantir que os usuários recebam o conteúdo mais atualizado sem servir stale cache por muito tempo.

A capacidade de personalizar o TTL de cache do navegador e o TTL de cache do edge permite que você ajuste sua estratégia de cache com base na frequência de atualização do seu conteúdo, nos padrões de tráfego do usuário e nos objetivos gerais de desempenho.

Saiba mais sobre expiration settings

Stale Cache garante a entrega de conteúdo quando uma requisição direcionada aos servidores de origem retorna um erro, a requisição sofre um timeout, os cabeçalhos do servidor são inválidos ou o arquivo está passando por uma atualização. Em vez de fornecer um erro aos usuários, o edge node verifica se há uma entrada de cache válida e a entrega, mesmo que esteja expirada.

Quando o Stale Cache está desativado e o servidor não consegue atualizar o cache a partir da origem, a aplicação retorna um erro 5xx ao usuário.

Saiba mais sobre stale cache

Adaptive Delivery detecta os grupos de dispositivos que você criou usando o Device Groups, permitindo que você configure como a Azion entrega seu conteúdo. Você pode optar por fornecer a mesma versão do conteúdo, independentemente da detecção do dispositivo, ou manter variações de objetos baseadas no dispositivo em cache.

Saiba mais sobre adaptive delivery

Large File Optimization é um recurso para Edge Application que processa grandes quantidades de dados de forma mais eficaz, reduzindo a latência e economizando em infraestrutura.

Ao habilitar essa funcionalidade, arquivos grandes são fragmentados em arquivos menores. Esses fragmentos são gradualmente entregues ao usuário final de acordo com o consumo de dados, evitando uma transferência abrupta de dados que poderia ser interrompida pelo usuário. A funcionalidade Large File Optimization armazena em cache os dados sob demanda no momento em que o usuário solicita, iniciando a operação do cache.

Saiba mais sobre configurações de large file optimization

Estes são os limites default:

EscopoLimite
Tamanho de slice de arquivos1.024 kB
Tamanho de objeto único em cache10 GB

Contribuidores