Cache de alto desempenho com NGINX e NGINX Plus

Owen GarrettDiretor Sênior de Gestão de Produtos

Sumário

Introdução

0:00 Introdução1:22 Sobre este webinar2:17 Princípios básicos do cache de conteúdo2:35 Princípios básicos3:59 Mecânica do cache HTTP7:46 O que o NGINX armazena em cache?

Cache de conteúdo e NGINX

9:55 NGINX em operação10:06 Configuração do NGINX11:14 Processo de cache15:32 O cache não serve apenas para HTTP17:10 Como entender o que está acontecendo17:38 Instrumentação do cache19:08 Instrumentação do cache (cont.)20:09 Status do cache21:57 Como funciona o cache de conteúdo no NGINX22:40 Como funciona23:53 Como o conteúdo em cache é armazenado?26:36 Carregamento do cache a partir do disco28:07 Gerenciamento do cache em disco29:22 Remoção de conteúdo do disco

Controle de cache

31:27 Controle de cache32:30 Cache adiado34:45 Controle do tempo de cache36:18 Armazenar / Não armazenar em cache37:25 Vários caches39:07 Revisão rápida – Por que usar cache?39:44 Por que a velocidade da página é importante?40:46 O Google mudou as regras41:28 Os custos do baixo desempenho43:00 O cache do NGINX permite que você45:21 Considerações finais

Perguntas e respostas

47:20 Solicitações de intervalos de bytes49:13 Revalidação do cache de proxy50:07 Distribuição do cache entre discos de mesma capacidade50:50 Vary Cabeçalho51:25 Primitivas de cache51:52 Cabeçalhos e dados do upstream52:13 *‑Encoding Cabeçalhos52:56 SPDY53:15 Vary Cabeçalho, 2ª rodada53:45 PageSpeed54:00 Outros caches

0:00 Introdução

Andrew Alexeev: Boas-vindas ao nosso mais recente webinar; meu nome é Andrew. NGINX foi desenvolvido por Igor Sysoev com o objetivo de ajudar os sites do mundo todo a funcionar com mais rapidez, responder melhor e ser facilmente escaláveis. Hoje, o NGINX está presente em mais de 30% dos principais sites e em mais de 20% de todos os sites da Internet. [Editor – Essas estatísticas eram válidas quando o webinar foi apresentado, em maio de 2014; consulte os valores atuais aqui.] Espero que o conteúdo deste webinar seja útil e aplicável ao seu ambiente NGINX atual ou planejado.

Agora, permitam-me apresentar Owen Garrett. Owen é responsável pelo desenvolvimento de produtos aqui na NGINX. Hoje, ele falará sobre como aplicar os poderosos mecanismos de cache do NGINX para livrar sua aplicação da tarefa de gerar repetidamente o mesmo conteúdo.

1:22 Sobre este webinar

Owen Garrett: Obrigado, Andrew. E, pessoal, muito obrigado por se juntarem a nós pelos próximos 45 ou 50 minutos. Vou explicar como o NGINX funciona em relação ao cache de conteúdo, veremos algumas maneiras de melhorar o desempenho, vamos nos aprofundar um pouco em como o cache de conteúdo realmente funciona para que vocês possam depurar e diagnosticar o que está acontecendo no NGINX e, por fim, compartilharei algumas dicas e sugestões inteligentes para que tenham um controle bastante granular sobre o que o NGINX faz com o conteúdo que pode ser armazenado em cache.

Tudo isso visando aos mesmos objetivos principais descritos por Andrew: aliviar dos servidores upstream a carga de gerar conteúdo repetitivo, deixando-os livres para executar os aplicativos de que sua empresa realmente precisa. Vá além desses servidores, oferecendo aos usuários finais um nível de serviço melhor e aumentando a confiabilidade do serviço como um todo diante de grandes picos de tráfego da Internet e, possivelmente, de falhas nos servidores upstream.

2:17 Princípios básicos do cache de conteúdo

Antes de entrarmos na configuração da implementação do NGINX, gostaria de fazer uma breve revisão de como o cache de conteúdo funciona, para que todos partamos do mesmo ponto, com a mesma base de informações essenciais.

2:35 Princípios básicos

O princípio básico do cache de conteúdo é reduzir o trabalho repetitivo dos servidores upstream. Quando o primeiro usuário solicita um item de conteúdo no site (representado pelo ícone azul e pelas linhas azuis), sua solicitação HTTP é encaminhada ao NGINX e, de lá, ao servidor upstream em cinza, no lado direito.

A resposta é encaminhada de volta ao usuário remoto, mas, se puder ser armazenada em cache (e falaremos em breve sobre o que isso significa), o NGINX armazena uma cópia dessa resposta. Quando outro usuário, o sujeito laranja, solicita o mesmo conteúdo, o NGINX pode fornecê-lo diretamente de seu cache local, em vez de encaminhar a solicitação ao servidor upstream.

Esse princípio básico de armazenar conteúdo inalterável que pode ser mantido em cache é usado pelo seu navegador, por uma CDN, pelos sites que você acessa, que utilizam CDNs, e pelo NGINX em outros dispositivos. Ele funciona como um cache de proxy reverso, normalmente implantado no data center ou na nuvem, próximo aos servidores de origem que hospedam seu conteúdo e suas aplicações web.

3:59 Mecânica do cache HTTP

O servidor de origem declara se o conteúdo pode ser armazenado em cache usando um ou mais cabeçalhos de resposta HTTP conhecidos e amplamente compreendidos. É claro que os servidores de cache podem optar por ignorar, substituir ou alterar esse comportamento. No entanto, para entender o armazenamento em cache de conteúdo configurado, é preciso começar compreendendo bem como um servidor de origem indica que o conteúdo pode ser armazenado em cache, que não sofre alterações e que a cópia [em cache] tem um determinado tempo de vida.

O armazenamento de conteúdo em cache começou com um cabeçalho de resposta HTTP simples chamado Expires. O servidor de origem fornecia determinado conteúdo e declarava que ele seria válido até a data indicada no cabeçalho Expires. Esse método foi rapidamente substituído por outro mais eficaz e flexível: o cabeçalho Cache-Control.

Expires é um tanto complicado de usar e ineficiente. As datas precisam ser formatadas e interpretadas corretamente, enquanto Cache-Control é muito mais simples e adequado às necessidades e à velocidade dos caches de conteúdo. Cache-Control define o conteúdo como público ou privado e, caso seja público, especifica um max-age – o número de segundos durante os quais ele pode permanecer em cache antes que o mecanismo de cache precise solicitar esse conteúdo novamente.

O terceiro cabeçalho que controla diretamente o cache é X-Accel-Expires. Esse cabeçalho é específico do NGINX; somente o NGINX o reconhece, e ele é usado quando você deseja substituir o comportamento dos cabeçalhos acima e informar diretamente ao NGINX por quanto tempo um item de conteúdo deve permanecer em cache.

Há situações em que você pode querer que o navegador armazene o conteúdo em cache por um longo período, mas prefira que o cache do proxy (o NGINX posicionado à frente do servidor de origem) o armazene por menos tempo, para que as alterações sejam refletidas mais rapidamente e disponibilizadas a novos clientes, enquanto os clientes antigos não continuem solicitando novamente o conteúdo sem necessidade.

No entanto, esse método também pode ser implementado usando os dois últimos cabeçalhos. Um servidor de origem pode informar quando um conteúdo foi modificado pela última vez e pode declarar algo chamado ETag (tag de entidade) – uma string opaca, geralmente um valor de hash, que identifica esse conteúdo.

Os clientes podem então fazer solicitações usando GETs condicionais. Eles podem incluir um cabeçalho If-Modified-Since ou If-None-Match na solicitação. Ao fazer isso, o cliente informa que possui uma versão do conteúdo em cache que foi modificada pela última vez em uma determinada data ou que tem uma ETag específica. Se a versão mais recente armazenada no servidor corresponder à versão que o cliente possui, o servidor responderá simplesmente com 304 Not Modified. Essa é uma resposta rápida que economiza largura de banda da rede e permite que o cliente verifique quando for conveniente se a cópia do conteúdo em cache ainda é válida.

Esses cinco cabeçalhos definem, da perspectiva de um servidor de origem, como o conteúdo pode ser armazenado em cache — sua validade, seu frescor e, no que diz respeito ao ETag, os detalhes do próprio conteúdo.

7:46 O que o NGINX armazena em cache?

Caches de proxy, como o NGINX, têm relativa liberdade para interpretar o grau de rigor com que seguirão esses cabeçalhos. É evidente que não devem armazenar em cache algo que não possa ser armazenado, mas, naturalmente, não têm obrigação de armazenar algo em cache só porque o servidor de origem diz que isso é permitido.

O comportamento básico do NGINX é armazenar em cache todas as solicitações GET e HEAD que o servidor de origem indicar como armazenáveis em cache, desde que não haja cabeçalhos Set-Cookie na resposta. Isso ocorre porque os cabeçalhos Set-Cookie normalmente incluem dados exclusivos de cada solicitação e, por padrão, não seria apropriado armazenar esse valor em cache.

O NGINX armazena cada recurso em cache usando uma chave específica — uma chave de cache. Todas as solicitações que gerarem a mesma chave de cache serão atendidas com o mesmo recurso. Por padrão, o cache é mapeado para a URL bruta ou, na configuração, para a string exibida neste slide [$scheme$proxy_host$uri$is_args$args]. Quando o NGINX armazena o conteúdo em cache, [o período de validade] é definido (em ordem de preferência) pelo cabeçalho X-Accel-Expires, se estiver presente, ou pelo cabeçalho Cache-Control, ou ainda pelo cabeçalho legado Expires.

Você pode configurar o NGINX para ignorar alguns desses cabeçalhos ou, em vez disso, definir um tempo de cache fixo, independentemente do que o servidor de origem informar. Para referência, a RFC 2616 define o comportamento esperado de um cache de proxy em relação ao HTTP.

Isso dá uma breve ideia da universalidade do armazenamento em cache e do comportamento padrão básico do NGINX ao armazenar em cache conteúdos que normalmente podem ser armazenados com segurança, a fim de acelerar seu site e reduzir a carga nos servidores de origem.

9:55 NGINX em operação

Agora, vamos dar uma olhada no NGINX em funcionamento. É muito, muito fácil configurar o NGINX para habilitar o cache de conteúdo.

10:06 Configuração do NGINX

São algumas linhas no seu arquivo de configuração do NGINX: uma para criar um cache em disco com um conjunto específico de parâmetros que definem como os arquivos são organizados, o prazo de expiração [dos objetos nesse cache] e o tamanho desse cache. A segunda, a diretiva proxy_cache, é associada a um proxy NGINX e informa que o conteúdo (resultados, respostas) deve ser armazenado em um cache nomeado.

Então, aqui criei um cache chamado one; ele ocupa 10 MB na memória para metadados, mas não há limite de espaço em disco para o conteúdo armazenado em cache. O conteúdo é armazenado em cache e depois removido caso permaneça inativo por 60 minutos. Esse cache chamado one é usado pelo nosso servidor padrão. Essas duas [diretivas], proxy_cache_path e proxy_cache, são suficientes para habilitar um armazenamento em cache confiável e consistente para um servidor proxy no NGINX.

11:14 Processo de cache

O processo pelo qual o NGINX passa ao receber uma solicitação e consultar um cache é definido da seguinte forma. Começamos lendo uma solicitação (caixa no canto superior esquerdo deste slide) e criando a chave de cache com base no URI bruto e nos outros parâmetros que usaremos para identificar o recurso correspondente a essa solicitação. Em seguida, verificamos o cache em disco acessando os metadados na memória para saber se temos uma cópia válida e atualizada da resposta a essa solicitação.

Se houver, isso será considerado um acerto. Assim, o NGINX poderá responder diretamente do cache. Ele faz isso fornecendo o conteúdo do disco exatamente como o NGINX fornece conteúdo estático. Dessa forma, você obtém o nível de desempenho, confiabilidade e escalabilidade para o qual o NGINX foi projetado. Ao fornecer conteúdo pelo cache de conteúdo do NGINX, você obtém exatamente o mesmo nível [de desempenho] do conteúdo estático.

Por outro lado, ao verificarmos o cache, pode ocorrer uma falha de cache. Isso significa que o conteúdo não está no cache ou que o conteúdo armazenado está desatualizado e precisa ser atualizado. No caso mais simples, essa falha significa que solicitamos o conteúdo ao servidor de origem, recebemos a resposta e verificamos se ela pode ser armazenada em cache.

Se for, nós o transmitimos para o disco, assim como o NGINX faz com qualquer resposta grande processada no modo proxy. Depois que ela [a resposta] é transmitida para o disco, nós a copiamos para o cache e respondemos diretamente a partir dele. Um dos desafios dessa abordagem ocorre quando o NGINX recebe várias solicitações para o mesmo conteúdo ao mesmo tempo e todas resultam em uma falha de cache.

Normalmente, o NGINX encaminharia todas essas solicitações ao servidor de origem, podendo sobrecarregá-lo — principalmente no caso de solicitações cujas respostas demoram muito para ser geradas. Por esse motivo, você pode usar um bloqueio de cache. A diretiva proxy_cache_lock garante que, se um conteúdo estiver sendo atualizado, apenas uma solicitação por vez seja enviada ao servidor upstream.

Portanto, no cenário que descrevi, a primeira solicitação seria enviada ao servidor upstream, mas as demais solicitações do mesmo conteúdo ficariam retidas até que a resposta fosse fornecida e inserida no cache (momento em que todas as solicitações poderiam ser atendidas) ou até que o tempo limite fosse atingido [definido pela diretiva proxy_cache_lock_timeout] – o NGINX aguardou tempo suficiente para que o conteúdo retornasse do servidor e, nesse momento, as solicitações retidas são encaminhadas ao servidor de origem.

Assim, o proxy_cache_lock e o tempo limite oferecem um controle avançado para garantir que, quando você tiver um site movimentado com muitas solicitações para o mesmo conteúdo, caso esse conteúdo expire no cache, o servidor de origem não seja subitamente sobrecarregado com várias solicitações.

Há mais um elemento no processo de armazenamento em cache do NGINX que não se encaixa perfeitamente neste fluxograma, pois abrange quase todas as etapas. Trata-se da funcionalidade configurada com a diretiva proxy_cache_use_stale. A qualquer momento, se uma dessas etapas falhar por algum motivo — por exemplo, quando estivermos atualizando o conteúdo e ocorrer um tempo limite, recebermos uma resposta inválida do servidor upstream ou houver algum outro tipo de erro —, teremos a opção de responder diretamente do cache, mesmo que o conteúdo armazenado esteja desatualizado.

Essa é uma ferramenta realmente poderosa para situações em que seus servidores upstream ficam sobrecarregados pelo tráfego ou falham devido a manutenção ou a um erro catastrófico. Ela garante que o NGINX possa continuar entregando seu conteúdo usando o conteúdo desatualizado do cache, em vez de retornar uma mensagem de erro ao cliente.

15:32 O cache não serve apenas para HTTP

O cache no NGINX não se limita ao HTTP. O NGINX é muito mais do que apenas um proxy HTTP que encaminha solicitações para servidores web upstream. Em geral, esses servidores web upstream servem para interagir com APIs como FastCGI ou SCGI. O NGINX pode fazer isso diretamente, atuando como proxy de forma muito semelhante ao proxy HTTP.

O NGINX pode empregar suas técnicas de cache para proxies HTTP, para proxies FastCGI, para proxies uWSGI e para proxies SCGI. Todos funcionam de maneira muito semelhante ao proxy HTTP, com caches armazenados em disco e respostas diretas, evitando a necessidade de encaminhar as solicitações a esses serviços upstream.

O NGINX também pode interagir com um servidor memcached; essa é uma abordagem de cache um pouco diferente. Nesse caso, o NGINX não armazena o conteúdo diretamente: ele usa o memcached como proxy e depende de um agente externo para preencher o memcached com o conteúdo necessário. Essa pode ser outra ferramenta útil, e há várias maneiras de preencher o memcached a partir de um site externo, se necessário. Portanto, você pode considerar isso uma forma de pré-carregar um cache para o NGINX, caso esse seja um requisito do seu negócio.

17:10 Como entender o que está acontecendo

O cache pode ser bastante complexo se você tiver uma grande infraestrutura com várias camadas, algumas fazendo cache, outras não, algumas gerando conteúdo, outras não. Nesse caso, pode ser um grande desafio começar a acompanhar o que está acontecendo — de onde vem o conteúdo —, além de diagnosticar e depurar quaisquer problemas encontrados. No NGINX, tornamos isso o mais fácil possível para você.

17:38 Instrumentação do cache

Com alguns recursos sofisticados de instrumentação, você pode controlar dinamicamente a instrumentação para rastrear a origem do conteúdo, onde ele está armazenado no cache e qual é o seu status no cache.

A primeira etapa é a variável $upstream_cache_status, que é calculada para cada solicitação à qual o NGINX respondeu, seja ela proveniente do cache ou não. Em seguida, você adiciona continuamente o valor dessa variável à resposta usando a diretiva add_header. Por convenção, colocamos esse valor em um cabeçalho X-Cache-Status na resposta. Ele pode assumir um de sete valores diferentes, indicando como esse conteúdo foi fornecido: se ignorou o cache, se veio de uma revalidação ou se foi um acerto de cache.

Este é o primeiro passo para tentar entender de onde vêm as respostas. Elas vêm do cache local do NGINX ou de um servidor upstream? Você pode inspecionar esse cabeçalho de resposta de várias maneiras – pela linha de comando, usando ferramentas como curl, ou, como é muito comum, pelo navegador da Web, usando ferramentas interativas de depuração.

É claro que talvez você não queira expor esse valor a todos os seus usuários finais. É recomendável escolher criteriosamente quando inserir esse valor no cabeçalho da resposta.

19:08 Instrumentação de cache (cont.)

A linguagem de configuração do NGINX oferece a flexibilidade necessária para você ser seletivo. Este exemplo mostra apenas uma das muitas maneiras de fazer isso. Pegamos o endereço remoto e, se ele for localhost, colocamos o $upstream_cache_status em uma variável temporária ($cache_status). Por fim, ao enviar uma resposta, incluímos a variável temporária nela.

Dessa forma, somente as solicitações provenientes de endereços IP específicos verão o valor da variável $upstream_cache_status. Você também pode fazer muitas outras coisas; em breve, veremos como o conteúdo é armazenado em disco. Você pode incluir na resposta a chave usada para calcular o local de armazenamento no disco. Também pode incluir todo tipo de parâmetro na resposta para ajudar a diagnosticar o cache enquanto ele está em execução.

20:09 Status do cache

NGINX Plus, nossa versão comercial do NGINX, oferece diversos recursos adicionais que ajudam em casos de uso como armazenamento em cache. O NGINX Plus é uma compilação do NGINX com suporte comercial, desenvolvida por nossa equipe de engenharia em Moscou e submetida a um amplo conjunto de testes de regressão para garantir seu funcionamento correto.

O NGINX Plus também inclui diversos recursos voltados para empresas que desejam usar o NGINX como proxy reverso e balanceador de carga. Entre eles estão recursos de balanceamento de carga, verificações de integridade e streaming avançado de vídeo. Nesse contexto, também há recursos de status estendido, diagnósticos aprimorados e visualização do que está acontecendo no NGINX.

[Editor – O slide acima e o parágrafo a seguir foram atualizados para fazer referência à API do NGINX Plus, que substitui e torna obsoleto o módulo de status separado discutido originalmente aqui.]

Para ver uma demonstração, acesse demo.nginx.com/dashboard.html e você verá uma página da Web que exibe os dados de status publicados pelo NGINX Plus por meio da API do NGINX Plus. E, se você executar o comando curl indicado, verá os dados JSON brutos obtidos diretamente do binário do NGINX Plus (aqui, eles são encaminhados para o utilitário jq para colocar cada elemento em uma linha separada e aplicar recuo hierárquico).

Nesses dados JSON, você encontrará informações em tempo real sobre o estado de cada cache na sua implantação do NGINX Plus. Isso, juntamente com a variável $upstream_cache_status e as outras formas de monitorar o cache, oferece uma visão geral muito boa de como o NGINX armazena conteúdo em cache e permite analisar solicitações individuais em detalhes para descobrir se elas vieram ou não do cache e qual é o status atual delas no cache.

21:57 Como funciona o cache de conteúdo no NGINX

Agora que vimos como podemos examinar o cache de conteúdo de fora, vamos analisá-lo por dentro. Como ele funciona no NGINX? Como mencionei anteriormente, o cache de conteúdo do NGINX funciona de maneira muito semelhante ao modo como os arquivos em disco são tratados. Ao disponibilizar conteúdo do nosso cache, você obtém o mesmo desempenho, a mesma confiabilidade e as mesmas otimizações do sistema operacional que teria ao disponibilizar conteúdo estático — o desempenho pelo qual o NGINX é reconhecido.

22:40 Como funciona

O cache de conteúdo é armazenado em disco de forma persistente. Trabalhamos em conjunto com o sistema operacional para transferir esse cache do disco para a memória, fornecendo indicações ao cache de páginas do sistema operacional sobre qual conteúdo deve ser mantido na memória. Isso significa que, quando precisamos fornecer conteúdo a partir do cache, podemos fazê-lo com extrema rapidez.

Os metadados do cache, como as informações sobre o que está armazenado e o prazo de expiração, são mantidos separadamente em uma área de memória compartilhada entre todos os processos do NGINX e permanecem sempre na memória. Assim, o NGINX pode consultar e pesquisar o cache com extrema rapidez; ele só precisa acessar o cache de páginas quando precisa recuperar a resposta e enviá-la ao usuário final.

Veremos como o conteúdo é armazenado no cache, como esse cache persistente é carregado em processos de trabalho vazios do NGINX durante a inicialização, algumas das tarefas de manutenção que o NGINX executa automaticamente no cache e, por fim, como você pode remover manualmente conteúdo do cache em situações específicas.

23:53 Como o conteúdo em cache é armazenado?

Lembre-se de que o cache de conteúdo é declarado usando uma diretiva chamada proxy_cache_path. Essa diretiva especifica vários parâmetros: onde o cache é armazenado no sistema de arquivos, o nome do cache, o tamanho do cache na memória para os metadados e o tamanho do cache no disco. Nesse caso, há um cache de 40 MB no disco.

A chave para entender onde o conteúdo é armazenado é compreender a chave de cache – o identificador exclusivo que o NGINX atribui a cada recurso que pode ser armazenado em cache. Por padrão, esse identificador é composto pelos parâmetros básicos da solicitação: o esquema, o cabeçalho Host, o URI e quaisquer argumentos de string.

Mas, se quiser, você pode ampliar isso usando elementos como valores de cookies, cabeçalhos de autenticação ou até mesmo valores calculados em tempo de execução. Talvez você queira armazenar versões diferentes para usuários do Reino Unido e dos EUA. Tudo isso é possível configurando a diretiva proxy_cache_key.

Quando o NGINX processa uma solicitação, ele calcula a proxy_cache_key e, com base nesse valor, calcula uma soma MD5. Você pode reproduzir esse processo usando o exemplo de linha de comando que mostrei mais abaixo no slide. Pegamos a chave de cache httplocalhost:8002/time.php e a passamos pelo comando md5sum. Ao fazer isso no shell, tome cuidado para não incluir também uma quebra de linha.

Isso calculará o valor de hash MD5 correspondente a esse conteúdo armazenável em cache. O NGINX usa esse valor de hash para calcular o local no disco em que o conteúdo deve ser armazenado. Você verá em proxy_cache_path que especificamos um cache de dois níveis, com um diretório de um caractere e, em seguida, outro de dois caracteres. Extraímos esses caracteres do final da string para criar um diretório chamado 4 e um subdiretório chamado 9b e, então, gravamos o conteúdo do cache (além dos cabeçalhos e de uma pequena quantidade de metadados) em um arquivo no disco.

Você pode testar o cache de conteúdo. É possível exibir a chave do cache como um dos cabeçalhos de resposta e passá-la pelo comando md5sum para calcular o hash correspondente a esse valor. Em seguida, você pode inspecionar o valor no disco para verificar se ele realmente está lá, bem como os cabeçalhos armazenados em cache pelo NGINX, e assim entender como tudo isso se encaixa.

26:36 Carregando o cache do disco

Agora que o conteúdo está armazenado em disco de forma persistente, quando o NGINX é iniciado, ele precisa carregar esse conteúdo na memória — ou melhor, precisa percorrer o cache em disco, extrair os metadados e, em seguida, carregá-los na memória, no segmento de memória compartilhada usado por cada um dos processos de trabalho. Isso é feito por meio de um processo chamado carregador de cache.

Um carregador de cache é iniciado durante a inicialização e executado uma única vez, carregando os metadados do disco em pequenos lotes: 100 arquivos por vez, com um limite de 200 ms, seguido de uma pausa de 50 ms. Esse processo se repete até que todo o cache tenha sido percorrido e o segmento de memória compartilhada esteja preenchido.

Em seguida, o carregador de cache é encerrado e não precisa ser executado novamente, a menos que o NGINX seja reiniciado ou reconfigurado e o segmento de memória compartilhada precise ser reinicializado. Você pode ajustar a operação do carregador de cache, o que pode ser apropriado se tiver discos muito rápidos e uma carga leve. É possível fazê-lo funcionar mais rapidamente ou talvez reduzir um pouco sua velocidade se você estiver armazenando um cache com um grande número de arquivos em discos lentos e não quiser que o carregador de cache use uma quantidade excessiva de CPU quando o NGINX for iniciado.

28:07 Gerenciando o cache em disco

Depois que o cache é carregado na memória e os arquivos são armazenados em disco, há o risco de que os arquivos em cache que nunca são acessados permaneçam ali para sempre. O NGINX os armazena na primeira vez que os encontra, mas, se não houver mais solicitações para um arquivo, [o arquivo] simplesmente ficará no disco até que algum processo o remova.

Esse algo é o gerenciador de cache; ele é executado periodicamente, removendo do disco os arquivos que não foram acessados durante determinado período e excluindo arquivos caso o cache esteja grande demais e tenha ultrapassado o tamanho definido. Ele os exclui seguindo o critério de menos recentemente usado. Você pode configurar essa operação usando parâmetros da proxy_cache_path [diretiva], assim como configura o carregador de cache:

• O tempo de inatividade padrão é de 10 minutos.
• O parâmetro max-size não tem um limite padrão. Se você impuser um limite de max-size ao cache, ele poderá exceder esse limite ocasionalmente, mas, quando o gerenciador de cache for executado, removerá os arquivos usados há mais tempo até que o cache volte a ficar abaixo desse limite.

29:22 Removendo conteúdo do disco

Por fim, há momentos em que você pode querer remover conteúdo do disco. Você precisa localizar um arquivo e excluí-lo; isso é relativamente fácil se você conhecer as técnicas que abordamos anteriormente — processar a chave do cache com md5sum — ou simplesmente executar um grep recursivo no sistema de arquivos para tentar identificar o arquivo ou os arquivos que você precisa excluir.

Como alternativa, se você estiver usando o NGINX Plus, poderá usar o recurso de limpeza de cache integrado ao produto. Esse recurso permite usar um parâmetro específico da solicitação; geralmente, usamos um método chamado PURGE para identificar que se trata de uma solicitação de limpeza de cache.

A limpeza é realizada por um manipulador especial do NGINX Plus, que inspeciona o URI e exclui do cache todos os arquivos correspondentes a esse URI. É possível adicionar um asterisco ao final do URI para transformá-lo em um prefixo. Neste caso, usaremos o recurso de limpeza para excluir todos os arquivos disponibilizados pelo host localhost na porta 8001, mas também seria possível especificar subdiretórios.

Independentemente do método usado, você pode excluir com total segurança, a qualquer momento, arquivos do cache em disco ou até mesmo executar rm -rf em todo o diretório de cache. O NGINX continuará funcionando normalmente e verificando a presença dos arquivos no disco. Se eles não estiverem lá, ocorrerá uma falha de cache. Em seguida, o NGINX recuperará o conteúdo do servidor de origem e o armazenará novamente no cache em disco. Portanto, excluir arquivos individuais do cache é sempre uma operação segura, confiável e estável.

31:27 Controlando o cache

Então, vimos como o cache funciona, analisamos a implementação no NGINX e nos aprofundamos na forma como ele armazena arquivos em disco para obter o mesmo tipo de desempenho alcançado com conteúdo estático. Agora, vamos usar o cache de forma um pouco mais inteligente.

Para sites simples, você pode ativar o cache e, em geral, ele fará exatamente o necessário para continuar oferecendo o nível de desempenho e o comportamento de cache desejados. No entanto, sempre há otimizações que podem ser feitas e, muitas vezes, o comportamento padrão não corresponde ao que você deseja.

Talvez seus servidores de origem não estejam definindo os cabeçalhos de resposta corretos, ou talvez você queira substituir as configurações especificadas por eles no próprio NGINX. Há inúmeras maneiras de configurar o NGINX para ajustar com precisão o funcionamento do cache.

32:30 Cache atrasado

Você pode adiar o armazenamento em cache. Essa é uma situação muito comum quando há um grande volume de conteúdo, boa parte do qual é acessada apenas uma ou duas vezes por hora ou por dia. Nesse caso, se você tiver um folheto da empresa que pouquíssimas pessoas leem, tentar armazenar esse conteúdo em cache geralmente é uma perda de tempo. O armazenamento em cache adiado permite definir um limite mínimo. Uma versão desse conteúdo só será armazenada em cache se ele tiver sido solicitado um determinado número de vezes. Até que esse limite de proxy_cache_min_uses seja atingido, nenhuma versão será armazenada em cache.

Isso permite que você seja mais criterioso ao decidir qual conteúdo será armazenado em cache. O cache em si é um recurso limitado, geralmente pela quantidade de memória disponível no servidor, pois é importante garantir que ele permaneça carregado na memória tanto quanto possível. Por isso, muitas vezes é recomendável limitar determinados tipos de conteúdo e armazenar em cache apenas as solicitações mais frequentes.

A revalidação de cache é um recurso adicionado recentemente ao NGINX Open Source e ao NGINX Plus. Ela modifica a funcionalidade If-Modified-Since para que, quando o NGINX precisar atualizar um valor armazenado em cache, ele não faça uma simples solicitação GET para obter uma nova versão desse conteúdo; em vez disso, ele faz uma solicitação GET condicional, informando: “Tenho uma versão em cache que foi modificada nesta data e hora específicas”.

O servidor de origem pode responder com 304 Não Modificado, indicando, na prática, que a versão que você tem ainda é a mais recente disponível. Isso economiza largura de banda no upstream; o servidor de origem não precisa reenviar conteúdo que não foi alterado e também pode reduzir as gravações em disco. O NGINX não precisa transmitir esse conteúdo para o disco e depois colocá-lo no lugar, sobrescrevendo a versão antiga.

34:45 Controle sobre o tempo de cache

Você tem controle granular sobre por quanto tempo o conteúdo deve permanecer em cache. Muitas vezes, o servidor de origem disponibiliza o conteúdo com cabeçalhos de cache adequados aos navegadores — armazenamento em cache de longo prazo, com solicitações relativamente frequentes para atualizar o conteúdo. No entanto, talvez você queira que o proxy NGINX posicionado diretamente à frente do servidor de origem atualize os arquivos com um pouco mais de frequência, para detectar as alterações mais rapidamente.

Há um enorme aumento na carga se você reduzir o tempo limite do cache dos navegadores de 60 segundos para 10 segundos, mas há um aumento muito pequeno na carga se você reduzir o tempo limite do cache no NGINX de 60 segundos para 10 segundos. Para cada solicitação, isso adicionará mais cinco solicitações por minuto aos seus servidores de origem, enquanto, no caso dos clientes remotos, tudo depende da quantidade de clientes com recursos semelhantes ativos no seu site.

Assim, você pode substituir a lógica e a intenção definidas pelo seu servidor de origem. Você pode ocultar ou instruir o NGINX a ignorar determinados cabeçalhos: X-Accel-Expires, Cache-Control ou Expires. Além disso, você pode definir um tempo de cache padrão usando a diretiva proxy_cache_valid na configuração do NGINX.

36:18 Armazenar em cache / Não armazenar em cache

Às vezes, talvez você não queira armazenar em cache um conteúdo que o servidor de origem informa ser armazenável em cache, ou talvez queira garantir que a versão do conteúdo armazenada no NGINX seja ignorada. As diretivas proxy_cache_bypass e proxy_no_cache oferecem esse nível de controle.

Você pode usá-las como um atalho para indicar que, se algum cabeçalho de um determinado conjunto de cabeçalhos de solicitação estiver definido, como o de autorização HTTP, ou se um parâmetro de solicitação estiver presente, o cache deverá ser ignorado — seja para atualizar automaticamente o cache no NGINX, seja para ignorá-lo completamente e sempre recuperar o conteúdo do servidor de origem.

Normalmente, isso é feito para decisões de cache bastante complexas, nas quais você toma decisões detalhadas com base nos valores dos cookies e dos cabeçalhos de autorização para controlar o que deve ser armazenado em cache, o que deve sempre ser obtido do servidor de origem e o que nunca deve ser armazenado no cache do NGINX.

37:25 Vários caches

Por fim, em implantações de grande escala, talvez seja interessante explorar o uso de vários caches em uma única instância do NGINX, por alguns motivos. Você pode ter políticas de cache diferentes para cada locatário no seu proxy NGINX, dependendo da natureza do site e da importância do desempenho dele — ou até mesmo do plano específico contratado por cada locatário em um ambiente de hospedagem compartilhada.

Ou talvez você tenha vários discos no host NGINX, e seja mais eficiente implantar um cache individual em cada disco. A regra de ouro é minimizar o número de cópias de um disco para outro. Para isso, você pode vincular um cache a cada disco e vincular ao disco correto o arquivo temporário de cada proxy que usa esse cache.

A operação padrão é a seguinte: quando o NGINX recebe conteúdo de um proxy upstream, ele grava esse conteúdo no disco à medida que o recebe, a menos que seja pequeno o suficiente para caber na memória. Depois que o conteúdo é gravado no disco, ele é movido para o cache. Essa operação é muito mais eficiente quando o local dos arquivos temporários (o disco em que eles são armazenados) é o mesmo disco em que o cache está armazenado.

39:07 Revisão rápida – Por que usar cache?

Então, falamos sobre cache, sobre os métodos usados pelo NGINX, sua implementação no NGINX e as formas de ajustá-lo. Agora que estamos chegando ao fim, vamos fazer uma breve revisão para relembrar por que é importante armazenar conteúdo em cache. O NGINX é usado em 114 milhões de sites no mundo todo, e muitos desses usuários o adotam por seus recursos de aceleração da Web e armazenamento de conteúdo em cache. [Editor – Essa estatística era válida quando o webinar foi realizado, em maio de 2014.]

39:44 Por que a velocidade da página é importante?

Esses recursos melhoram a velocidade de um site – proporcionando aos usuários finais uma experiência melhor – e a velocidade das páginas é realmente muito importante. Há anos, analistas monitoram o comportamento dos usuários e formulam o que é conhecido informalmente como a “regra dos N segundos”. Esse é o tempo que um usuário comum está disposto a esperar até que uma página seja carregada e exibida antes de ficar entediado e impaciente e migrar para outro site, o de um concorrente.

À medida que os padrões melhoraram e as expectativas dos usuários aumentaram cada vez mais, o tempo que eles estão dispostos a esperar vem diminuindo continuamente. Com alguns cálculos um tanto duvidosos, seria possível extrapolar essa tendência e concluir que, por volta de 2016, os usuários teriam um nível negativo de paciência.

40:46 O Google mudou as regras

Mas, na verdade, a tecnologia nos ultrapassou. O Google ilustrou isso graficamente há alguns anos, ao lançar o Google Instant Search. Agora, no Google, quando você digita um termo na caixa de pesquisa, antes mesmo de terminar, o Google já apresenta possíveis resultados. Isso demonstra a enorme mudança nas expectativas em relação à Internet moderna. Como o próprio Google afirmou, “os usuários agora esperam que as páginas da web respondam da mesma forma que as páginas de um livro ao serem viradas” — com a mesma rapidez, naturalidade e fluidez.

41:28 Os custos do baixo desempenho

Se você não atingir esse nível de desempenho, poderá haver impactos significativos nos KPIs associados ao seu site ou serviço web. No caso das taxas de cliques em anúncios, o próprio Google constatou uma queda de 20% quando suas páginas de pesquisa demoraram meio segundo a mais para carregar. Quanto à receita, em um experimento para investigar o efeito da lentidão das páginas web, a Amazon aumentou deliberadamente o tempo de carregamento em incrementos de 100 ms e constatou que a receita gerada pelos clientes afetados geralmente caía 1% a cada aumento de 100 ms.

Muitos outros analistas, sites e pesquisadores relataram efeitos semelhantes nas métricas de um site, como tempo na página, taxa de rejeição etc. Mais recentemente, o Google passou a levar em consideração a velocidade da página ao calcular sua classificação nos resultados de pesquisa. O que parece contar é o tempo até o primeiro byte. Quanto mais tempo leva para receber o primeiro byte durante o carregamento de uma página, maior é a penalização na classificação. Um site pode acabar nem sequer sendo acessado por aparecer na terceira, quarta ou quinta página dos resultados de pesquisa do Google.

43:00 O cache do NGINX permite que você

Os recursos de cache do NGINX permitem melhorar a experiência do usuário final, reduzindo o tempo até o primeiro byte e tornando o conteúdo da web mais ágil e responsivo.

O NGINX permite consolidar e simplificar sua infraestrutura web. O NGINX não é apenas um cache web independente. Ele inclui um servidor web de origem e um gateway direto para APIs como FastCGI. Além disso, o NGINX Plus oferece os recursos necessários para criar um balanceador de carga sofisticado e pronto para uso empresarial, bem como um controlador de entrega de aplicações. Isso permite consolidar diversos componentes de rede da sua infraestrutura web em um único componente — NGINX ou NGINX Plus —, proporcionando soluções mais confiáveis, rápidas e fáceis de depurar.

O NGINX permite aumentar a capacidade dos servidores ao retirar tarefas repetitivas dos servidores upstream. Na verdade, mesmo para conteúdos que parecem não poder ser armazenados em cache (como a página inicial de um blog, por exemplo), vale a pena mantê-los em cache por apenas um segundo no proxy NGINX.

Quando cem usuários solicitam o mesmo conteúdo no mesmo segundo, o NGINX reduz isso a uma única solicitação ao servidor de origem e fornece o conteúdo a esses usuários a partir do cache, garantindo que ele nunca esteja desatualizado em mais de um segundo. Isso costuma ser mais do que suficiente para um blog ou site semelhante e, ainda assim, faz uma enorme diferença no desempenho — tanto na carga dos servidores upstream quanto nos custos de gerenciamento e implantação da capacidade necessária.

Por fim, não se esqueça de um dos usos estratégicos do NGINX: proteger você contra falhas nos servidores upstream por meio do recurso “use stale” do cache de proxy. Se eles estiverem lentos, retornando erros ou apresentando algum tipo de falha, o NGINX poderá recorrer à versão local do conteúdo armazenada em cache e continuar usando-a até que os servidores upstream se recuperem.

45:21 Considerações finais

38% dos sites mais acessados do mundo usam o NGINX principalmente por seus recursos de aceleração da Web e armazenamento de conteúdo em cache. [Editor – Essa estatística era válida quando o webinar foi apresentado, em maio de 2014; consulte o valor atual aqui.] Para conhecer mais soluções e obter mais detalhes, confira os blogs e os resumos de recursos em nginx.com, que abordam os recursos do NGINX e do NGINX Plus. Confira também nossa lista de webinars, que inclui não apenas os próximos webinars, mas também webinars de eventos anteriores desta série, que serão adicionados em breve.

E, se quiser explorar melhor esses recursos, é claro que há a documentação e as soluções disponíveis em nginx.org e nginx.com, mas nada melhor do que baixar e experimentar. O produto de código aberto está disponível em nginx.org, e o produto comercial com suporte, que oferece recursos adicionais de balanceamento de carga, entrega de aplicações, gerenciamento e facilidade de uso, está disponível em nginx.com.

Então, pessoal, muito obrigado pelo tempo e pela atenção de vocês. Espero que esta apresentação e esta visão geral do cache de conteúdo no NGINX tenham sido úteis e esclarecedoras para muitos de vocês.

Perguntas e respostas

Vamos começar a responder às perguntas e ver como nos saímos.

47:20 Solicitações de intervalo de bytes

Temos uma pergunta sobre solicitações de intervalos de bytes. As solicitações de intervalos de bytes são usadas quando um cliente solicita um conteúdo, mas precisa apenas de uma parte dele. Digamos que seja um arquivo de vídeo e o cliente precise apenas de um trecho do vídeo. Outro caso muito comum é o de um arquivo PDF: o usuário leu os cabeçalhos que contêm um índice do arquivo PDF, e o cliente quer baixar apenas um determinado conjunto de páginas. Como isso funciona no cache de conteúdo do NGINX?

O processo funciona da seguinte forma. Quando o NGINX recebe uma solicitação de intervalo de bytes para um recurso e o recurso inteiro já está no cache, o NGINX responde usando o cache com o intervalo de bytes solicitado pelo cliente. Se esse recurso não estiver no cache, o NGINX solicitará o recurso inteiro ao servidor upstream e o armazenará no cache. Atualmente, nesse momento, o NGINX não atenderá à solicitação de intervalo de bytes e retornará o recurso inteiro ao cliente. Na maioria das situações, esse é um comportamento aceitável.

Por exemplo, se um cliente estiver baixando um documento PDF, sua primeira solicitação será, de qualquer forma, para o documento inteiro. Somente se esse documento for transmitido por streaming é que o cliente interromperá a conexão e começará a fazer solicitações de intervalos de bytes. Portanto, para conteúdo armazenado em cache, o NGINX atende às solicitações de intervalos de bytes. Para conteúdo não armazenado em cache, o NGINX recupera todo o conteúdo do servidor upstream e, nessa ocasião, retorna o conteúdo inteiro ao cliente.

49:13 Revalidação do cache de proxy

Esta é uma pergunta sobre o recurso de revalidação do cache de proxy. Esse recurso permite que o NGINX faça uma solicitação condicional GET ao servidor upstream para verificar se o conteúdo foi alterado. A pergunta é:

A revalidação do cache do proxy leva em consideração os ETags ou apenas a data de If-Modified-Since do conteúdo?

A resposta é que ele verifica apenas a data If-Modified-Since do conteúdo e, na prática, geralmente é recomendável sempre incluir If-Modified-Since nas suas respostas e tratar os ETags como opcionais, pois eles não são tratados de forma tão consistente nem tão ampla quanto a data de “última modificação” que você incluirá na resposta.

50:07 Distribuindo o cache entre discos de mesma capacidade

É possível fazer com que o NGINX balanceie o armazenamento em cache de um único site entre vários discos idênticos para obter o melhor desempenho?

Sim, é possível, mas exige um pouco de trabalho. O cenário típico consiste em implantar vários discos sem RAID e, em seguida, implantar caches individuais, cada um vinculado a um disco. Isso requer algumas configurações adicionais e o particionamento do tráfego. Se precisar de ajuda com essa configuração, entre em contato com a nossa comunidade para tratarmos da sua solicitação específica por lá ou, se estiver usando o NGINX Plus, entre em contato com a nossa equipe de suporte, que terá prazer em ajudar.

50:50 Vary Cabeçalho

O NGINX leva em consideração o cabeçalho Vary para determinar acertos e falhas de cache?

Não, o NGINX não processa automaticamente os cabeçalhos Vary. Se isso for um problema, basta adicionar o cabeçalho Vary à chave de cache do proxy para que a chave exclusiva usada para armazenar a resposta inclua o valor do cabeçalho Vary. Assim, você pode armazenar várias versões diferentes.

51:25 Primitivas de cache

Todas as primitivas e diretivas de cache estão sendo respeitadas?

Em geral, sim. Há alguns casos extremos, como os cabeçalhos Vary, que não são respeitados. Em muitos casos, há certa margem de interpretação quanto à forma como os diversos caches entendem os requisitos da RFC. Sempre que possível, optamos por implementações confiáveis, consistentes e fáceis de configurar.

51:52 Cabeçalhos e dados do upstream

Tanto os cabeçalhos quanto os dados do upstream estão sendo armazenados em cache?

Sim. Se você receber uma resposta do cache, tanto os cabeçalhos quanto o corpo da resposta estarão armazenados em cache.

52:13 *‑Encoding Cabeçalhos

Os valores dos cabeçalhos são armazenados em cache junto com o corpo da resposta, então… eu ficaria bastante surpreso se o NGINX não funcionasse corretamente com as diversas combinações de Transfer-Encoding. O Accept-Encoding costuma ser implementado por meio de um cabeçalho Vary, portanto, os comentários anteriores sobre a necessidade de incluir cabeçalhos Vary na chave do cache também se aplicam nesse caso (para clientes que não oferecem suporte a isso).

52:56 SPDY

O cache funciona com SPDY?

Com certeza. Você pode pensar nele como um proxy de frontend para o NGINX, embora, na prática, ele esteja profundamente integrado ao kernel do NGINX. Sim, o SPDY funciona com cache.

53:15 Vary Header, 2ª rodada

Aqui vai outra pergunta sobre o cabeçalho Vary. Só para confirmar: se você estiver usando respostas com o cabeçalho Vary e gzip, dê uma olhada em algumas das discussões no Trac ou em nosso site da comunidade para encontrar soluções para isso. A abordagem mais comum é incorporar o cabeçalho Vary à chave de cache.

53:45 PageSpeed

P: O PageSpeed usa o cache do NGINX ou seu próprio mecanismo de cache?

Essa é uma pergunta que você precisaria fazer aos desenvolvedores do PageSpeed.

54:00 Outros caches

P: Como outros caches de conteúdo se comparam ao NGINX?

As CDNs são soluções muito eficazes para armazenamento de conteúdo em cache. As CDNs são disponibilizadas como um serviço; você tem um controle mais limitado sobre como o conteúdo é armazenado em cache e como ele expira nesse ambiente, mas elas são uma ferramenta extremamente eficaz para aproximar o conteúdo dos usuários finais. O NGINX é uma ferramenta muito eficaz para acelerar aplicações web e é muito comum que ambos sejam implantados em conjunto. No caso de caches independentes, como o Varnish, mais uma vez, são tecnologias extremamente eficientes que, em muitos aspectos, funcionam de maneira semelhante ao NGINX. Uma das vantagens do NGINX é reunir gateways de aplicações que atendem à origem, armazenamento em cache e balanceamento de carga em uma única solução. Isso proporciona uma infraestrutura mais simples e consolidada, que é mais fácil de implantar, gerenciar, depurar e diagnosticar caso ocorram problemas.

Para assistir ao webinar no qual este post se baseia, acesse-o aqui.

Para experimentar o NGINX Plus, inicie hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett