Solução de problemas

Caso você encontre os problemas a seguir ao usar o Cloud CDN, veja as etapas de solução que podem ser úteis.

Problemas comuns e soluções

As respostas não estão sendo armazenadas em cache

Se as respostas não estão sendo armazenadas em cache, primeiro confirme se o Cloud CDN está ativado no serviço ou no intervalo de back-end. Quando você ativa o Cloud CDN, pode levar alguns minutos até que as respostas comecem a ser armazenadas em cache.

O Cloud CDN armazena em cache somente respostas marcadas como públicas e que especificam a data de expiração ou a idade máxima. Essa informação é fornecida nos cabeçalhos de respostas HTTP. Se as respostas para um URL não estiverem sendo armazenadas em cache, confirme quais cabeçalhos HTTP estão sendo retornados para esse URL.

Há várias maneiras de verificar cabeçalhos de respostas:

O exemplo a seguir demonstra como usar a curl para verificar os cabeçalhos de respostas HTTP para http://example.com/style.css:

$ curl -s -D - -o /dev/null http://example.com/style.css
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

$

A comparação entre esses cabeçalhos e os requisitos em Detalhes do armazenamento em cache mostra que a resposta não tem o cabeçalho Cache-Control necessário.

O método para definir cabeçalhos depende do tipo de servidor de origem. Se você estiver executando um servidor da Web no Google Compute Engine, consulte a documentação do software do servidor da Web para detalhes sobre como configurar cabeçalhos de resposta. No Google Cloud Storage, se o objeto for marcado como compartilhado publicamente, os cabeçalhos apropriados serão enviados.

Depois que você reconfigurar o servidor de origem para adicionar o cabeçalho necessário, a curl pode ser usada novamente para verificar o resultado:

$ curl -s -D - -o /dev/null http://example.com/style.css
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

$ curl -s -D - -o /dev/null http://example.com/style.css
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

$ curl -s -D - -o /dev/null http://example.com/style.css
HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

$

A última resposta neste exemplo inclui o cabeçalho Age. O Cloud CDN adiciona um cabeçalho Age a respostas que veicula do cache. Aqui, o cabeçalho indica que a resposta foi veiculada a partir do cache com êxito usando uma entrada de cache criada há dois segundos.

O conteúdo particular foi armazenado em cache ou está incorreto

Se você souber por que o servidor de origem veiculou conteúdo particular ou incorreto e puder corrigir o problema, será possível invalidar os caches do Cloud CDN usando o seguinte processo:

  1. Certifique-se de que o servidor de origem não retornará mais o conteúdo particular ou incorreto.
  2. Solicite uma invalidação de cache para instruir o Cloud CDN a parar de disponibilizar o conteúdo armazenado em cache.

Para mais informações, acesse a página de invalidação de cache.

O Cloud CDN armazenará em cache somente respostas marcadas como armazenáveis em cache publicamente e veiculará respostas do cache até a data de expiração especificada nelas. Desative o Cloud CDN se você não souber por que o conteúdo foi armazenado em cache ou tiver dificuldade para corrigir, entender e resolver o problema. Depois, ative-o novamente. Para mais informações sobre qual conteúdo é armazenado em cache e por quanto tempo, consulte os Detalhes do armazenamento em cache.

A taxa de ocorrência em cache está baixa ou há vários preenchimentos de cache para o mesmo conteúdo

Se as taxas de ocorrência em cache dos serviços ou dos intervalos de back-end estiverem mais baixas do que o esperado, confirme se as respostas para os URLs em questão estão sendo armazenadas em cache.

O Cloud CDN incorpora o URI de solicitação completo nas chaves de cache. Portanto, http://example.com/cat.jpg?1 e http://example.com/cat.jpg?2 terão entradas de cache separadas. Você pode melhorar as taxas de ocorrência em cache sempre usando apenas um URL para determinado recurso. Se você precisar transmitir parâmetros para o JavaScript em execução em uma página armazenável em cache, use identificadores de fragmentos em vez de strings de consulta. Além disso, use o cabeçalho de resposta Vary (apenas quando for necessário) para melhorar as taxas de ocorrência em cache. Os Detalhes do armazenamento em cache têm mais informações sobre chaves de cache.

Em geral, você pode reduzir o número de preenchimentos de cache modificando as datas de expiração das suas respostas armazenáveis. Como todo o resto é o mesmo, você verá menos preenchimentos de cache para uma resposta com Cache-Control: public, max-age=86400 do que uma com Cache-Control: public, max-age=1. Consulte os Detalhes do armazenamento em cache para saber mais sobre as datas de expiração. Acesse a documentação do seu software de servidor da Web para ver detalhes sobre como configurar os cabeçalhos de resposta adequados. Porém, observe que o Cloud CDN opera vários caches pelo mundo e, rotineiramente, entradas de cache antigas são excluídas para dar espaço a conteúdos novos. Consequentemente, vários preenchimentos de cache por recurso são esperados como parte da operação normal.

A compactação não está funcionando

O Cloud CDN em si não compacta nem descompacta as respostas, mas pode veicular as respostas geradas pelo servidor de origem que são compactadas com codificações dos tipos gzip e DEFLATE.

Se as respostas veiculadas pelo Cloud CDN não forem compactadas conforme o necessário, confirme se o software do servidor da Web em execução nas suas instâncias está configurado para compactar respostas. Por padrão, alguns softwares de servidor da Web desativam automaticamente a compactação de solicitações que incluem o cabeçalho Via. A presença de um cabeçalho Via indica que a solicitação foi encaminhada por um proxy. Os proxies HTTP, como balanceamento de carga HTTP(S), adicionam um cabeçalho Via a cada solicitação, conforme exigido pela especificação HTTP. Para ativar a compactação, pode ser necessário modificar a configuração padrão do seu servidor da Web para que ele compacte respostas mesmo que a solicitação tenha um cabeçalho Via.

Se você estiver usando o software do servidor da Web nginx, modifique o arquivo de configuração nginx.conf para ativar a compactação. O local deste arquivo depende de onde o nginx está instalado. Em muitas distribuições do Linux, o arquivo fica armazenado em /etc/nginx/nginx.conf. Para permitir que a compactação do nginx funcione com o balanceamento de carga HTTP(S), adicione as duas linhas abaixo à seção http do nginx.conf:

gzip_proxied any;
gzip_vary on;

A primeira linha ativa a compactação até mesmo para solicitações encaminhadas por um proxy como o balanceamento de carga HTTP(S). A segunda linha adiciona um cabeçalho Vary: Accept-Encoding às respostas. Vary: Accept-Encoding notifica proxies de armazenamento em cache, como o Cloud CDN, de que precisam manter entradas de cache separadas para variantes compactadas e não compactadas de recursos compactáveis.

Após modificar o nginx.conf, você precisa reiniciar o nginx antes que ele use a nova configuração. Em muitas distribuições do Linux, o nginx pode ser reiniciado ao executar sudo service nginx restart ou /etc/init.d/nginx restart.

As respostas são encerradas com erros byte_range_caching_aborted

Quando o Cloud CDN agrupa uma resposta de várias solicitações de intervalo de bytes, ele verifica se esses intervalos são da mesma versão do recurso por meio da comparação entre os cabeçalhos de resposta "ETag" e "Last-Modified". Se o Cloud CDN constatar que o valor de um dos cabeçalhos é inconsistente com os intervalos que ele já veiculou ao cliente, ele abortará a resposta.

Caso você observe respostas encerradas inesperadamente, entradas de registro do Stackdriver Logging com statusDetails byte_range_caching_aborted ou instâncias retornando respostas 412 Precondition Failed, certifique-se de que o software do servidor da Web em execução em todas as instâncias de VM retorne os mesmos valores de "ETag" e "Last-Modified" do recurso em questão.

Ao disponibilizar arquivos a partir do disco, é comum que o software do servidor da Web derive os valores de "ETag" e "Last-Modified" do horário de modificação do arquivo. Nesse caso, é possível garantir que as instâncias de VM relatem valores consistentes usando a mesma imagem para todas as instâncias. Consulte a documentação do seu software do servidor da Web para ver detalhes de como ele determina os valores de "ETag" e "Last-Modified".

Mensagens de erro

Erros de invalidação de cache
Código de erro Observações
Invalid value for field 'resource.path' O valor do caminho tinha um formato inválido. Os caminhos precisam começar com /, não podem conter ? ou # e precisam ter apenas um * como caractere final após uma /. Os caminhos não podem ter mais de 1.024 caracteres. Se você receber esse erro, verifique o valor do caminho e corrija quaisquer erros de formatação.
Este erro aborda somente o formato do caminho. Um caminho com formato válido, mas que não existe, ainda é considerado válido.
Rate Limit Exceeded O Cloud CDN restringe a frequência das operações de invalidação de cache. Somente uma invalidação por minuto é permitida. Porém, cada operação pode especificar um padrão de caminho que corresponda a qualquer número de objetos.

Problemas conhecidos

Os seguintes problemas e limitações conhecidos afetam o Cloud CDN:

  • As invalidações de cache têm uma limitação de uma invalidação por mapa de URL/minuto.
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud CDN