Uma taxa de acerto de cache baixa aumenta o tráfego de retorno à origem, eleva o consumo de largura de banda e retarda a entrega de recursos. Use as ferramentas de monitoramento e as estratégias de otimização para diagnosticar a causa e melhorar sua taxa.
Como funciona o cache do CDN
O Alibaba Cloud CDN armazena conteúdo estático em pontos de presença (POPs) distribuídos globalmente. Quando uma requisição atinge o cache, o POP entrega o recurso diretamente, sem ida e volta à origem. Uma taxa de acerto de cache baixa indica que mais requisições chegam à origem, o que aumenta a latência, os custos de largura de banda e a carga do servidor.
Taxa de acerto de bytes vs. taxa de acerto de requisições
O CDN rastreia duas métricas:
|
Métrica |
Fórmula |
Quando usar |
|
Taxa de acerto de bytes |
(Tráfego entregue pelos POPs L1 − Tráfego de retorno à origem entregue pelos POPs L1) ÷ Tráfego entregue pelos POPs L1 |
Métrica padrão; reflete a eficiência da largura de banda |
|
Taxa de acerto de requisições |
Requisições que atingem o cache do CDN ÷ Total de requisições ao CDN |
Métrica secundária |
Priorize a taxa de acerto de bytes na maioria dos casos. Uma taxa menor significa maior tráfego de retorno à origem, o que eleva os custos de largura de banda e a carga do servidor de origem. Se a busca de intervalo na origem estiver ativada, use sempre a taxa de acerto de bytes como métrica principal.
Monitorar a taxa de acerto de cache
In the console
O console do CDN exibe a taxa de acerto de bytes. Dois modos de monitoramento estão disponíveis, conforme a janela de tempo necessária:
|
Modo |
Intervalo de tempo |
Granularidade |
Latência de dados |
|
Resource Monitoring |
Períodos longos, como 30 dias |
5 minutos |
~15 minutos |
|
Real-time monitoring |
Períodos curtos, como 1 hora |
1 minuto |
~3 minutos |
Para analisar tendências históricas, use o Resource Monitoring.
Para diagnósticos imediatos, use o Real-time monitoring.
Via API
Use estas operações de API para recuperar dados de taxa de acerto programaticamente:
Resource Monitoring (dados de até 90 dias)
|
API |
Descrição |
|
Taxa de acerto de bytes para um nome de domínio acelerado |
|
|
Taxa de acerto de requisições para um nome de domínio acelerado |
Real-time monitoring (dados de até 7 dias, granularidade de 1 minuto)
|
API |
Descrição |
|
Taxa de acerto de bytes em tempo real para um nome de domínio acelerado |
|
|
Taxa de acerto de requisições em tempo real para um nome de domínio acelerado |
Melhorar a taxa de acerto de cache
Ao identificar uma taxa de acerto de cache baixa, verifique qual cenário abaixo corresponde à sua situação e aplique a correção correspondente.
|
Causa |
Cenário |
Solução |
|
Ausência de pré-busca antes de picos de tráfego |
Os recursos não ficam armazenados em cache nos POPs antes do lançamento de um produto ou evento promocional importante. Assim, todas as requisições iniciais vão para a origem. |
Faça a pré-busca de recursos antes dos horários de pico. Consulte Atualizar e fazer pré-busca de recursos. |
|
TTL muito curto ou não configurado |
Os POPs não têm política de cache ou os recursos em cache expiram antes de novas solicitações. |
Defina um tempo de vida (TTL) adequado ao tipo de conteúdo. Consulte Configure um TTL. |
|
Parâmetros de string de consulta fragmentam o cache |
O mesmo recurso é solicitado por URLs que diferem apenas nos parâmetros da string de consulta. Cada variante passa a ser tratada como uma entrada de cache distinta. |
Remova os parâmetros da string de consulta da chave de cache com o recurso Ignore parameters. Consulte Ignore Parameters. |
|
Downloads parciais aumentam o tráfego de retorno à origem |
Um usuário baixa parte de um arquivo grande (como um pacote de instalação ou vídeo), mas o POP busca o arquivo inteiro na origem para atender à requisição. |
Ative a busca de intervalo na origem para que os POPs recuperem apenas o intervalo de bytes solicitado. Consulte Configure busca de intervalo na origem. |
Diretrizes de TTL por tipo de conteúdo
Defina valores de TTL com base na frequência de alteração do conteúdo:
|
Tipo de conteúdo |
Exemplos |
TTL recomendado |
|
Conteúdo estático atualizado com pouca frequência |
Imagens, pacotes de instalação |
1 mês ou mais |
|
Conteúdo estático atualizado frequentemente |
Arquivos JavaScript, CSS |
1 dia a 1 semana, dependendo da frequência de atualização |
|
Conteúdo dinâmico |
Arquivos PHP, JSP, ASP |
0s (desativar cache) |
Se você usar nomes de arquivo versionados (como app.v2.js), poderá definir um TTL mais longo com segurança, pois cada nova versão cria uma nova entrada de cache.
Casos de uso de pré-busca
A pré-busca é especialmente eficaz em dois cenários:
Atividades promocionais: Antes de lançar uma campanha em grande escala, envie recursos estáticos da página da atividade para os POPs. Quando a atividade entrar no ar, o cache atenderá todas as requisições, sem idas e voltas à origem.
Lançamentos de software: Antes de liberar uma nova versão ou pacote de atualização, faça a pré-busca para os POPs. Dessa forma, as requisições de download são atendidas diretamente pela borda, o que reduz a carga da origem e melhora as velocidades de download.
Políticas avançadas de otimização
O Alibaba Cloud CDN oferece os seguintes recursos avançados para cenários específicos. Para ativar qualquer um deles, entre em contato com o suporte técnico do Alibaba Cloud:
Agendamento centralizado 302 — redireciona requisições para o POP com o conteúdo em cache e evita buscas redundantes na origem em toda a rede CDN.
Agendamento de borda 302 — executa agendamento baseado em redirecionamento na borda para encaminhar usuários a um POP próximo que já possui o recurso.
Busca de origem mesclada — quando vários POPs solicitam simultaneamente o mesmo recurso fora do cache, apenas uma requisição vai para a origem. A resposta é compartilhada entre todos os POPs solicitantes.
Cache compartilhado — permite que vários nomes de domínio acelerados compartilhem um único pool de cache, o que aumenta as taxas de acerto quando os domínios servem conteúdos sobrepostos.
Ler status de acerto de cache nos logs
Os logs de requisição do CDN registram o status de acerto de cache para cada requisição. Para obter o formato completo do log, consulte Campos em logs offline.
O campo HIT/MISS em cada entrada de log indica se o cache atendeu à requisição:
|
Valor |
Significado |
|
|
O cache do POP atendeu à requisição. |
|
|
A requisição não estava em cache no POP e foi encaminhada à origem. |
O status de acerto reflete apenas os POPs L1. Uma requisição que falha em um POP L1, mas acerta em um POP L2, ainda é registrada como MISS .
Exemplo de entrada de log:
26/Jun/2019:10:38:19 +0800] 192.168.53.146 - 1542 "-" "GET http://example.aliyundoc.com/index.html" 200 191 2830 MISS "Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://example.com/robot/)" "text/html"Para baixar logs offline programaticamente, chame DescribeCdnDomainLogs para obter as URLs de download do seu nome de domínio acelerado.
Próximos passos
Atualize e fazer pré-busca de recursos — envie conteúdo para os POPs antes do pico de tráfego
Configure um TTL — defina políticas de expiração de cache por tipo de conteúdo
Ignore Parameters — consolide entradas de cache divididas por strings de consulta
Configure busca de intervalo na origem — otimize a entrega de arquivos grandes