BLOG | NGINX

Cache de alto desempenho com NGINX e NGINX Plus

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Owen Garrett
Owen Garrett
Publicado em 24 de agosto de 2016

Imagem dos apresentadores do webinar High-Performance Caching
Este post é uma adaptação de um webinar de Owen Garrett, apresentado por Andrew Alexeev.

Índice

INTRODUÇÃO

0:00 INTRODUÇÃO
1:22 Sobre este webinar
2:17 Princípios básicos do cache de conteúdo
2:35 Princípios básicos
3:59 Mecânica do cache HTTP
7:46 O que o NGINX armazena em cache?

Cache de conteúdo e NGINX

9:55 NGINX em operação
10:06 Configuração NGINX
11:14 Processo de cache
15:32 O cache não é apenas para HTTP
17:10 Como entender o que está acontecendo
17:38 Instrumentação de cache
19:08 Instrumentação de Cache (Cont.)
20:09 Status do cache
21:57 Como o cache de conteúdo funciona no NGINX
22:40 COMO FUNCIONA
23:53 Como o conteúdo em cache é armazenado?
26:36 Carregando cache do disco
28:07 Gerenciando o cache de disco
29:22 Limpando conteúdo do disco

Controlando o cache

31:27 Controlando o cache
32:30 Cache atrasado
34:45 Controle sobre o tempo de cache
36:18 Cache / Não armazenar em cache
37:25 Vários Caches
39:07 Revisão rápida – Por que cache?
39:44 Por que a velocidade da página é importante?
40:46 O Google mudou as regras
41:28 Os custos do mau desempenho
43:00 O cache NGINX permite que você
45:21 Considerações Finais

Perguntas e respostas

47:20 Solicitações de intervalo de bytes
49:13 Revalidação de cache proxy
50:07 Distribuindo o cache em discos iguais
50:50 Cabeçalho Variável
51:25 Primitivos de cache
51:52 Cabeçalhos e dados upstream
52:13 *‑Cabeçalhos de codificação
52:56 RÁPIDO
53:15 Cabeçalho Variável , Rodada 2
53:45 Velocidade da página
54:00 Outros Caches

0:00 Introdução

André Alexeev : Bem-vindos ao nosso último webinar; meu nome é Andrew. O NGINX foi escrito por Igor Sysoev com a ideia de ajudar os sites do mundo a rodarem mais rápido, serem mais responsivos e facilmente escaláveis. Hoje, o NGINX alimenta mais de 30% dos principais sites e mais de 20% de todos os sites na Internet. [ Editor – Essas estatísticas se aplicavam quando o webinar foi entregue em maio de 2014; veja os valores atuais aqui . ] Espero que você ache o conteúdo deste webinar útil e aplicável ao seu ambiente NGINX existente ou planejado.

Agora, deixe-me apresentar Owen Garrett a você. Owen é responsável pelo desenvolvimento de produtos aqui na NGINX. Hoje, Owen vai falar sobre como você pode aplicar mecanismos poderosos de cache no NGINX para liberar seu aplicativo do fardo de gerar conteúdo repetitivo repetidamente.

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. Falarei sobre como o NGINX funciona em relação ao cache de conteúdo , veremos algumas maneiras de melhorar o desempenho, nos aprofundaremos um pouco em como o cache de conteúdo realmente funciona para que você esteja preparado para depurar e diagnosticar o que está acontecendo no NGINX e resumirei com algumas dicas e sugestões inteligentes para lhe dar um controle realmente refinado sobre o que o NGINX faz com o conteúdo que pode ser armazenado em cache.

Todos visando os mesmos motivos principais, como Andrew descreveu, para tirar o fardo dos seus servidores upstream de gerar conteúdo repetitivo para que eles fiquem livres para executar os aplicativos que sua empresa realmente precisa. Aumente além desses servidores, dando aos seus usuários finais um melhor nível de serviço e aumentando a confiabilidade do seu serviço como uma brecha diante de grandes picos de tráfego da Internet e, potencialmente, falhas de servidores upstream.

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

Antes de entrarmos na configuração de implementação do NGINX, gostaria de revisar rapidamente como o cache de conteúdo funciona para que todos comecemos da mesma página, da mesma linha de base de informações essenciais.

2:35 Princípios Básicos

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

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

Este princípio básico de armazenar conteúdo armazenável em cache e imutável é usado pelo seu navegador da web, por uma CDN, pelos sites que você está acessando, pelas CDNs de aproveitamento e pelo NGINX em outros dispositivos. Ele opera como um cache proxy reverso , normalmente implantado no data center ou na nuvem, próximo aos servidores de origem que hospedam seu conteúdo e aplicativos da web.

3:59 Mecânica do Cache HTTP

O servidor de origem declara a capacidade de armazenamento em cache do conteúdo usando um ou mais dos vários cabeçalhos de resposta HTTP bem compreendidos e conhecidos. É claro que os servidores de cache podem optar por ignorar, substituir ou alterar esse comportamento. Mas para entender o cache de conteúdo configurado, você realmente precisa começar com um bom entendimento da maneira como um servidor de origem indicará que o conteúdo pode ser armazenado em cache, é imutável e que a cópia [armazenada em cache] tem um certo tempo de vida.

O cache de conteúdo começou com um cabeçalho de resposta HTTP simples chamado Expires . O servidor de origem apresentaria algum conteúdo e declararia que esse conteúdo seria válido até a data no cabeçalho Expires . Esse método foi rapidamente substituído por um método mais eficaz e flexível – o cabeçalho Cache-Control .

Expires é um pouco complicado de usar; é ineficiente. As datas precisam ser formatadas e analisadas corretamente, enquanto o Cache-Control é muito mais simplificado e alinhado às necessidades e à velocidade dos caches de conteúdo. Cache-Control declara o conteúdo como público ou privado e, no caso de ser público, declara um max-age – o número de segundos que ele pode ser armazenado em cache antes que o objeto de cache precise solicitar novamente esse conteúdo.

O terceiro cabeçalho que controla diretamente o cache é o X-Accel-Expires . Este cabeçalho é especial para o NGINX; somente o NGINX o entende e ele é usado se você quiser substituir o comportamento dos cabeçalhos acima e informar diretamente ao NGINX por quanto tempo um item de conteúdo deve ser armazenado em cache.

Há situações em que você pode querer que o navegador da web armazene o conteúdo em cache por um longo período de tempo, mas você está feliz que o cache do proxy (NGINX na frente do servidor de origem) o armazene em cache por um período de tempo mais curto para que as alterações sejam refletidas mais rapidamente e enviadas para novos clientes, enquanto os clientes antigos não ficam solicitando novamente o conteúdo quando não precisam.

No entanto, esse método também pode ser implementado usando os dois últimos cabeçalhos. Um servidor de origem pode declarar quando um item de conteúdo foi modificado pela última vez e pode declarar algo chamado ETag (entity tag) – uma string opaca, geralmente um valor 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 em sua solicitação. Ao fazer isso, o cliente está declarando que tem uma versão em cache do conteúdo que foi modificado pela última vez em uma data específica ou tem uma ETag específica. Se a versão mais recente que o servidor possui corresponder à versão que o cliente possui, o servidor responderá simplesmente com um 304Não modificado . Esta é uma resposta rápida que economiza largura de banda de rede e permite que o cliente verifique quando quiser se a cópia em cache do conteúdo ainda é válida.

Esses cinco cabeçalhos definem, da perspectiva do servidor de origem, como o conteúdo pode ser armazenado em cache: sua validade, seu frescor e, em termos de ETag , os detalhes do conteúdo em si.

7:46 O que o NGINX armazena em cache?

Caches proxy como o NGINX são relativamente livres para interpretar quão rigorosamente eles obedecerão a esses cabeçalhos. É claro que eles não deveriam armazenar em cache algo que não é armazenável em cache, mas é claro que eles não têm nenhuma obrigação de armazenar em cache algo se o servidor de origem disser que é armazenável em cache.

O comportamento básico do NGINX é armazenar em cache todas as solicitações GET e HEAD que são indicadas pelo servidor de origem 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 específicos para cada solicitação e, por padrão, não seria apropriado armazenar esse valor em cache.

O NGINX armazena em cache cada recurso por uma chave específica – uma chave de cache. Todas as solicitações que geram a mesma chave de cache serão atendidas com o mesmo recurso. Por padrão, o cache mapeia para a URL bruta ou, na configuração, a string ilustrada neste slide [ $scheme$proxy_host$uri$is_args$args ]. No momento em que o NGINX armazena o conteúdo em cache, [o tempo de vida útil] é definido (em ordem de preferência) pelo cabeçalho X-Accel-Expires, se presente, ou pelo cabeçalho Cache-Control ou pelo cabeçalho Expires legado.

Você pode ajustar o NGINX para mascarar alguns desses cabeçalhos ou fornecer um tempo de cache fixo, independentemente do que o servidor de origem diz. Para referência, o RFC 2616 define o comportamento desejado de um cache proxy em relação ao HTTP.

Isso lhe dará uma breve noção da universalidade do cache e do comportamento padrão básico do NGINX no cache de conteúdo que normalmente é seguro para cache, a fim de acelerar seu site e aliviar a carga de seus servidores de origem.

9:55 NGINX em operação

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

10:06 Configuração NGINX

São algumas linhas no seu arquivo de configuração NGINX – uma para criar um cache no disco com um determinado conjunto de parâmetros declarando como os arquivos são dispostos, o tempo de expiração [para objetos naquele 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 cache em um cache nomeado.

Então, aqui, criei um cache chamado one ; ele tem 10 MB de tamanho na memória para metadados, mas tamanho ilimitado no disco para conteúdo armazenado em cache. O conteúdo é armazenado em cache e depois coletado se ficar inativo por 60 minutos. O cache chamado um é usado pelo nosso servidor padrão. Essas duas [diretivas], proxy_cache_path e proxy_cache , são suficientes para habilitar o cache confiável e consistente para um servidor proxy no NGINX.

11:14 Processo de cache

O processo pelo qual o NGINX passa quando recebe uma solicitação e consulta um cache é definido da seguinte forma. Começamos lendo uma solicitação (caixa superior esquerda neste slide), montando a chave de cache para o URI bruto e os outros parâmetros que usaremos para identificar o recurso correspondente a essa solicitação. Em seguida, verificamos o cache no disco acessando os metadados na memória para ver se temos uma cópia válida e atualizada da resposta para essa solicitação.

Se fizermos isso, será considerado um acerto. Então o NGINX pode responder diretamente do cache. Ele responde do cache servindo o conteúdo do disco exatamente como o NGINX serve conteúdo estático. Assim, você obtém o nível de desempenho, confiabilidade e escalabilidade para os quais o NGINX foi projetado. Com conteúdo estático, você obtém exatamente o mesmo grau [de desempenho] quando serve conteúdo do cache de conteúdo do NGINX.

Por outro lado, quando verificamos o cache, podemos ter uma falha de cache. Isso significa que não temos o conteúdo no cache ou o conteúdo no cache está desatualizado e precisa ser atualizado. No caso mais simples, então, essa falha significa que iríamos solicitar esse conteúdo do servidor de origem, receber a resposta e verificar se ele pode ser armazenado em cache.

Se for, nós o transmitimos para o disco, assim como o NGINX faz para qualquer resposta grande manipulada no modo proxy. Então, quando [a resposta] é transmitida para o disco, nós a copiamos para o cache e respondemos diretamente do cache. Um dos desafios dessa abordagem é se o NGINX recebe várias solicitações para o mesmo conteúdo ao mesmo tempo e todas elas resultam em falhas.

O NGINX normalmente encaminharia todas essas solicitações para o servidor de origem, potencialmente sobrecarregando-o, principalmente para solicitações que demoram muito para gerar respostas. 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.

Então, no cenário que descrevi, a primeira solicitação iria para o servidor upstream, mas as solicitações restantes para o mesmo conteúdo seriam retidas até que a resposta fosse atendida e inserida no cache (momento em que todas as solicitações podem ser atendidas) ou um tempo limite fosse atingido [definido pela diretiva proxy_cache_lock_timeout ] – o NGINX esperou tempo suficiente para que o conteúdo retornasse do servidor e, nesse ponto, as solicitações que você liberou são encaminhadas para o servidor de origem.

Portanto, o proxy_cache_lock e o timeout oferecem um controle poderoso para garantir que, quando você tiver um site ocupado com muitas solicitações para o mesmo conteúdo, se esse conteúdo expirar no cache, você não sobrecarregue repentinamente o servidor de origem com várias solicitações.

Há mais um elemento no processo de cache no NGINX que não se encaixa perfeitamente neste fluxograma porque ele abrange quase todos os estágios do gráfico. Esse é o recurso configurado com a diretiva proxy_cache_use_stale . A qualquer momento, se um desses estágios falhar por algum motivo, por exemplo, quando estamos atualizando o conteúdo e o tempo limite é atingido ou recebemos uma resposta incorreta do servidor upstream ou algum outro tipo de erro, temos a opção de responder diretamente do cache, mesmo que o conteúdo armazenado em cache esteja desatualizado.

Esta é uma ferramenta realmente poderosa caso seus servidores upstream estejam sobrecarregados pelo tráfego ou falhem devido a manutenção ou erro catastrófico. Ele garante que o NGINX possa continuar a entregar seu conteúdo usando o conteúdo obsoleto do cache em vez de retornar uma mensagem de erro ao cliente.

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

O cache no NGINX não é apenas para HTTP. O NGINX é muito mais do que apenas um proxy HTTP que encaminha solicitações para servidores web upstream. Geralmente, esses servidores web upstream estão lá para interagir com APIs como FastCGI ou SCGI. O NGINX pode fazer isso diretamente em um modo proxy 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 operam da mesma forma que o proxy HTTP, com caches armazenados em disco e respostas diretas, evitando a necessidade de proxy para esses serviços upstream.

O NGINX também pode interagir com um servidor memcached; esta é uma abordagem de cache um pouco diferente. Neste caso, o NGINX não armazena 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. Esta pode ser outra ferramenta útil, e há muitas maneiras de preencher o memcached de um site externo, se necessário. Então você pode considerar isso como uma forma de semear um cache para o NGINX se esse for o seu requisito comercial.

17:10 Como entender o que está acontecendo

O cache pode ser potencialmente muito complexo se você tiver uma grande infraestrutura com várias camadas, algumas fazendo cache, outras não, algumas gerando conteúdo, outras não; então pode ser um grande desafio começar a rastrear o que está acontecendo – de onde o conteúdo está vindo – e diagnosticar e depurar quaisquer problemas que você encontrar. No NGINX, facilitamos tudo para você o máximo possível.

17:38 Instrumentação de cache

Com alguma instrumentação sofisticada, você tem a capacidade de controlar a instrumentação dinamicamente para rastrear de onde o conteúdo está vindo, onde ele está armazenado no cache e qual é o status no cache.

O primeiro passo é a variável $upstream_cache_status , que é calculada para cada solicitação que o NGINX respondeu, seja do cache ou não. E você adiciona continuamente o valor dessa variável à sua resposta usando a diretiva add_header . Convencionalmente, colocamos esse valor em um cabeçalho X-Cache-Status na resposta. Ele pode assumir um de sete valores diferentes, declarando como aquele pedaço de conteúdo foi veiculado. Se ele ignorou o cache, se veio de uma revalidação, se foi um acerto.

Este é o primeiro passo para tentar entender de onde vêm suas respostas. Eles vêm do cache NGINX local ou de um servidor upstream? E você pode inspecionar esse cabeçalho de resposta de várias maneiras – na linha de comando usando ferramentas como curl ou, muito comumente, no seu navegador da web usando depuradores interativos.

É claro que você pode não querer declarar esse valor para todos os seus usuários finais. Você deve ser seletivo quanto ao momento de inserir esse valor na resposta do cabeçalho.

19:08 Instrumentação de Cache (Cont.)

A linguagem de configuração do NGINX oferece a flexibilidade de ser seletivo. Este exemplo mostra apenas uma das muitas maneiras de fazer isso. Pegamos o endereço remoto e, se for localhost, colocaremos o $upstream_cache_status em uma variável temporária ( $cache_status ). Por fim, quando enviamos uma resposta, colocamos uma variável temporária na resposta.

Dessa forma, apenas solicitações de endereços IP seletivos 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 no disco. Você pode colocar a chave usada para calcular a localização no disco na resposta. Você pode colocar todos os tipos de parâmetros na resposta para ajudar a diagnosticar o cache enquanto ele está em execução.

20:09 Status do cache

O NGINX Plus , nossa versão comercial do NGINX, oferece uma série de recursos adicionais que ajudam em casos de uso como cache. O NGINX Plus é uma versão comercialmente suportada do NGINX criada por nossa equipe de engenharia em Moscou e executada por meio de um amplo conjunto de testes de regressão para garantir a operação correta.

O NGINX Plus também contém uma série de recursos direcionados a empresas que desejam usar o NGINX como um proxy reverso e balanceador de carga. Recursos sobre balanceamento de carga, verificações de integridade e streaming de vídeo avançado. E no contexto disso, recursos em torno de status estendido, melhores diagnósticos e visualização do que está acontecendo no NGINX.

[Editor – O slide acima e o parágrafo seguinte foram atualizados para se referir à API NGINX Plus , que substitui e desaprova o módulo de status separado originalmente discutido aqui.]

Para uma demonstração, você pode ir para demo.nginx.com/dashboard.html e verá uma página da web que exibe os dados de status que são publicados do NGINX Plus usando a API do NGINX Plus . E se você executar o comando curl indicado, verá os dados JSON brutos que são retirados diretamente do binário do NGINX Plus (aqui, eles são canalizados para o utilitário jq para colocar cada elemento em sua própria linha e recuados hierarquicamente).

Nesses dados JSON, você encontrará dados em tempo real sobre o estado de cada um dos caches na sua implantação do NGINX Plus. Isso, junto com a variável $upstream_cache_status e outras maneiras de instrumentar o cache, fornece uma visão geral muito boa de como o NGINX armazena o conteúdo em cache e permite que você analise as solicitações individuais para descobrir se a solicitação veio do cache ou não e o status atual dentro do cache.

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

Agora, tendo visto como podemos examinar o cache de contato de fora, vamos dar uma olhada nele de dentro. Como funciona no NGINX? Como mencionei anteriormente, o cache de conteúdo no NGINX funciona da mesma maneira que os arquivos no disco são manipulados. Você obtém o mesmo desempenho, a mesma confiabilidade, as mesmas otimizações do sistema operacional quando você está servindo conteúdo do nosso cache de conteúdo como você obtém quando você serve conteúdo estático - o desempenho pelo qual o NGINX é conhecido.

22:40 Como funciona

O cache de conteúdo é armazenado em disco em um cache persistente. Trabalhamos em conjunto com o sistema operacional para trocar o cache de disco para a memória, fornecendo dicas ao cache de páginas do sistema operacional sobre qual conteúdo deve ser armazenado na memória. Isso significa que quando precisamos servir conteúdo do cache, podemos fazê-lo extremamente rápido.

Os metadados em torno do cache, informações sobre o que está lá e seu tempo de expiração, são armazenados separadamente em uma seção de memória compartilhada entre todos os processos NGINX e estão sempre presentes na memória. Assim, o NGINX pode consultar o cache e pesquisar no cache extremamente rápido; ele só precisa ir ao cache da página quando precisa extrair a resposta e fornecê-la de volta ao usuário final.

Veremos como o conteúdo é armazenado no cache, como esse cache persistente é carregado em processos de trabalho NGINX vazios na inicialização, veremos algumas das manutenções que o NGINX faz automaticamente no cache e, para finalizar, veremos como você pode podar manualmente o conteúdo do cache em situações específicas.

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

Você se lembra que o cache de conteúdo é declarado usando uma diretiva chamada proxy_cache_path . Esta diretiva especifica o número de parâmetros: onde o cache é armazenado no seu sistema de arquivos, o nome do cache, o tamanho do cache na memória para os metadados e o tamanho do cache no disco. Neste caso, há um cache de 40 MB no disco.

A chave para entender onde o conteúdo é armazenado é entender a chave de cache – o identificador exclusivo que o NGINX atribui a cada recurso armazenável em cache. Por padrão, esse identificador é criado a partir dos parâmetros básicos da solicitação: o esquema, o cabeçalho do host , o URI e quaisquer argumentos de string.

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

Quando o NGINX manipula uma solicitação, ele calcula o proxy_cache_key e, a partir desse valor, calcula uma soma MD5. Você pode replicar isso sozinho usando o exemplo de linha de comando que mostrei mais abaixo no slide. Pegamos a chave de cache httplocalhost:8002/time.php e a enviamos através do md5sum . Tenha cuidado ao fazer isso a partir do casco para não bombear uma nova linha também.

Isso calculará o valor de hash MD5 que corresponde ao conteúdo armazenável em cache. O NGINX usa esse valor de hash para calcular o local no disco onde o conteúdo deve ser armazenado. Você verá no proxy_cache_path que especificamos um cache de dois níveis com um diretório de um caractere e depois um diretório de dois caracteres. Retiramos esses caracteres do final da string para criar um diretório chamado4 e um subdiretório chamado 9b , e então colocamos o conteúdo do cache (mais os cabeçalhos e uma pequena quantidade de metadados) em um arquivo no disco.

Você pode testar o cache de conteúdo. Você pode imprimir a chave de cache como um dos cabeçalhos de resposta e pode enviá-la por meio do md5sum para calcular a correspondência de hash desse valor. Então você pode inspecionar o valor no disco para ver se ele realmente está lá e os cabeçalhos que o NGINX armazenou em cache, para entender como tudo isso se encaixa.

26:36 Carregando cache do disco

Agora que o conteúdo está armazenado no disco e é persistente, quando o NGINX é iniciado, ele precisa carregar esse conteúdo na memória – ou melhor, ele precisa percorrer o cache do disco, extrair os metadados e então carregar os metadados na memória no segmento de memória compartilhada usado por cada um dos processos de trabalho. Isso é feito usando um processo chamado cache loader .

Um carregador de cache é iniciado na inicialização e executado uma vez, carregando metadados no disco em pequenos pedaços: 100 arquivos por vez, colocados em sandbox por 200 ms, pausando por 50 ms entre eles e repetindo até que tenha percorrido todo o cache e preenchido o segmento de memória compartilhada.

O carregador de cache então sai 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 você tiver discos muito rápidos e uma carga leve. Você pode fazê-lo rodar mais rápido ou talvez queira retroceder um pouco se estiver armazenando um cache com um grande número de arquivos e discos lentos e não quiser que o carregador de cache use quantidades excessivas de CPU quando o NGINX for inicializado.

28:07 Gerenciando o cache de disco

Uma vez que o cache está na memória e os arquivos são armazenados no disco, há o risco de que os arquivos em cache que nunca são acessados fiquem para sempre. O NGINX os armazenará na primeira vez que os vir, mas se não houver mais solicitações para um arquivo, então [o arquivo] ficará lá no disco até que algo apareça e o limpe.

Essa coisa é o gerenciador de cache ; ele é executado periodicamente, limpando arquivos do disco que não foram acessados dentro de um certo período de tempo e exclui arquivos se o cache for muito grande e tiver excedido o tamanho declarado. Ele os exclui de acordo com os menos usados recentemente. Você pode configurar esta operação usando parâmetros para proxy_cache_path [diretiva], assim como você configura o carregador de cache:

  • O tempo inativo padrão é 10 minutos.
  • O parâmetro max-size não tem limite padrão. Se você impuser um limite de tamanho máximo ao cache, às vezes ele poderá exceder esse limite, mas quando o gerenciador de cache for executado, ele removerá os arquivos menos usados recentemente para colocá-los novamente abaixo desse limite.

29:22 Limpando conteúdo do disco

Por fim, há momentos em que você pode desejar limpar conteúdo do disco. Você quer encontrar um arquivo e excluí-lo; é relativamente fácil fazer isso se você conhece as técnicas que falamos anteriormente – executar a chave de cache por meio do md5sum – ou apenas executar um grep recursivo no sistema de arquivos para tentar identificar o arquivo ou arquivos que você precisa excluir.

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

A limpeza é feita por um manipulador NGINX Plus especial que inspeciona o URI e exclui todos os arquivos que correspondem a esse URI do cache. O URI pode ser sufixado com um asterisco para que se torne uma haste. Neste caso, usaremos o recurso de purga para excluir todos os arquivos fornecidos pela porta 8001 do host localhost, mas é claro que você também pode colocar subdiretórios.

Seja qual for o método usado, a qualquer momento você estará totalmente seguro para excluir arquivos do cache no disco ou até mesmo executar rm -rf em todo o diretório de cache. O NGINX não perderá o ritmo; ele continuará verificando a presença de arquivos no disco. Se eles estiverem faltando, isso criará uma falha de cache. O NGINX então recuperará o cache do servidor de origem e o armazenará de volta no cache do disco. Portanto, é sempre seguro, confiável e estável caso você precise limpar arquivos individuais do cache.

31:27 Controlando o cache

Então, vimos como o cache funciona, analisamos a implementação dentro do NGINX e nos aprofundamos em como ele armazena arquivos no disco para obter o mesmo tipo de desempenho que obtém com conteúdo estático. Agora vamos ficar um pouco mais espertos sobre cache.

Para sites simples, você pode ativar o cache e, geralmente, ele fará exatamente o que precisa para continuar oferecendo o nível de desempenho e o comportamento de cache que você deseja. Mas sempre há otimizações a serem feitas e muitas vezes há situações em que o comportamento padrão não corresponde ao comportamento que você deseja.

Talvez seus servidores de origem não estejam configurando os cabeçalhos de resposta corretos ou talvez você queira substituir o que eles estão especificando dentro do próprio NGINX. Há uma infinidade de maneiras de configurar o NGINX para ajustar o funcionamento do cache.

32:30 Cache atrasado

Você pode atrasar o armazenamento em cache. Essa é uma situação muito comum se você tem um grande acervo de conteúdo, grande parte do qual é acessado apenas uma ou duas vezes por hora ou por dia. Nesse caso, se você tem o folheto da sua empresa que poucas pessoas leem, geralmente é perda de tempo tentar armazenar esse conteúdo em cache. O cache atrasado permite que você coloque uma marca d'água. Ele só armazenará uma versão em cache deste conteúdo se ele tiver sido solicitado um certo número de vezes. Até que você atinja a marca d'água proxy_cache_min_uses , ele não armazenará uma versão no cache.

Isso permite que você tenha mais discernimento sobre qual conteúdo vai para seu cache. O cache em si é um recurso limitado, normalmente limitado pela quantidade de memória que você tem no seu servidor, porque você vai querer garantir que o cache seja paginado na memória o máximo possível. Então, muitas vezes você deseja limitar certos tipos de conteúdo e colocar apenas as solicitações populares no seu cache.

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

O servidor de origem tem a opção de responder com 304Não modificado , o que significa efetivamente que a versão que você tem ainda é a versão mais recente que existe. Isso economiza largura de banda upstream; o servidor de origem não precisa reenviar conteúdo que não foi alterado e também economiza potencialmente em gravações em disco. O NGINX não precisa transmitir esse contato para o disco e depois trocá-lo de lugar, substituindo a versão antiga.

34:45 Controle sobre o tempo de cache

Você tem controle preciso sobre por quanto tempo o conteúdo deve ser armazenado em cache. Muitas vezes, o servidor de origem fornecerá conteúdo com cabeçalhos de cache apropriados para os navegadores – cache de longo prazo com uma solicitação relativamente frequente para atualizar o conteúdo. No entanto, você pode querer que o proxy NGINX fique diretamente na frente do seu servidor de origem para atualizar os arquivos com um pouco mais de frequência, para captar alterações mais rapidamente.

Há um grande aumento na carga se você reduzir o tempo limite do cache para os navegadores de 60 segundos para 10 segundos, mas há um aumento muito pequeno na carga se você aumentar o tempo limite do cache no NGINX de 60 segundos para 10 segundos. Para cada solicitação, serão adicionadas mais cinco solicitações por minuto aos seus servidores de origem, enquanto com os clientes remotos, tudo depende do número de clientes com coisas semelhantes ativas no seu site.

Então, você pode substituir a lógica e a intenção que seu servidor de origem diz. Você pode mascarar ou dizer ao NGINX para ignorar determinados cabeçalhos: X-Accel-Expires , Cache-Control ou Expires . E você pode fornecer um tempo de cache padrão usando a diretiva proxy_cache_valid na sua configuração do NGINX.

36:18 Cache / Não Armazenar em Cache

Às vezes, você pode não armazenar em cache o conteúdo que o servidor de origem diz que pode ser armazenado em cache, ou pode querer garantir que você ignore a versão do conteúdo armazenado no NGINX. As diretivas proxy_cache_bypass e proxy_no_cache dão a você esse grau de controle.

Você pode usá-los como um atalho para dizer que se qualquer um de um determinado conjunto de cabeçalhos de solicitação estiver definido, como autorização HTTP, ou um parâmetro de solicitação estiver presente, então você deseja ignorar o cache – seja para atualizar automaticamente o cache no NGINX ou simplesmente ignorá-lo completamente e sempre recuperá-lo do servidor de origem.

Normalmente, isso é feito para decisões de cache bastante complexas, onde você toma decisões detalhadas sobre os valores de cookies e cabeçalhos de autorização para controlar o que deve ser armazenado em cache, o que deve sempre ser recebido do servidor de origem e o que nunca deve ser armazenado no cache do NGINX.

37:25 Vários Caches

Por fim, para implantações em larga escala, talvez você queira explorar vários caches em uma instância individual do NGINX, por alguns motivos. Você pode ter diferentes políticas de cache para diferentes locatários no seu proxy NGINX, dependendo da natureza do seu site e da importância do desempenho desse site – até mesmo dependendo do plano específico para o qual cada locatário está inscrito em uma situação de hospedagem compartilhada.

Ou você pode ter vários discos no host NGINX e é 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. Você pode fazer isso fixando um cache em cada disco e fixando o arquivo temporário de cada proxy que usa esse cache no disco correto.

A operação padrão é que quando o NGINX recebe conteúdo de um proxy upstream, ele transmite esse conteúdo para o disco, a menos que seja suficientemente pequeno e caiba na memória. Então, quando o conteúdo for transmitido para o disco, ele será movido para o cache. Essa operação é infinitamente mais eficiente se o local no cache para os arquivos temporários (o disco onde os arquivos temporários são armazenados) for o mesmo que o disco onde o cache é armazenado.

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

Então falamos sobre cache, falamos sobre os métodos que o NGINX usa, a implementação dentro do NGINX e maneiras de ajustá-lo. À medida que nos aproximamos do encerramento, vamos fazer uma revisão rápida para nos lembrarmos por que você deseja armazenar conteúdo em cache em primeiro lugar. O NGINX é implantado em 114 milhões de sites no mundo todo e muitos desses usuários implantam o NGINX por causa de suas capacidades de aceleração da web e cache de conteúdo. [ Editor – Esta estatística foi aplicada quando o webinar foi entregue em maio de 2014. ]

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

Esses recursos melhoram a velocidade de um site – eles oferecem aos usuários finais um melhor nível de experiência – e a velocidade da página da web é muito, muito importante. Durante anos e anos, os analistas têm monitorado o comportamento do usuário e criado o que é coloquialmente conhecido como a “regra dos N segundos”. É quanto tempo um usuário médio está disposto a esperar para que uma página carregue e seja renderizada antes de ficar entediado e impaciente e migrar para um site diferente, de um concorrente.

À medida que os padrões melhoram e as expectativas dos usuários aumentam cada vez mais, o período que os usuários estão dispostos a esperar está diminuindo cada vez mais. Você poderia, por meio de uma matemática um pouco duvidosa, extrapolar isso e concluir que os usuários terão um nível negativo de paciência por volta de 2016.

40:46 O Google mudou as regras

Mas, na verdade, a tecnologia nos ultrapassou. O Google ilustrou isso graficamente alguns anos atrás, ao apresentar o Google Instant Search. Agora, com o Google, quando você digita um termo de pesquisa em uma caixa de pesquisa, antes mesmo de terminar de digitar, o Google apresenta resultados de pesquisa de candidatos. Isso ilustra a enorme mudança nas expectativas em relação à Internet moderna. Como o próprio Google disse, “os usuários agora esperam que as páginas da web reajam da mesma forma que as páginas viradas de um livro reagem” – tão rápida, tão perfeitamente e tão fluidamente.

41:28 Os custos do mau desempenho

Se você não atingir esse nível de desempenho, poderá haver impactos significativos no KPI que você vincula ao seu site ou serviço web. Sejam taxas de cliques em anúncios: O próprio Google descobriu que a taxa de cliques em seus anúncios caiu 20% quando suas páginas de pesquisa demoraram meio segundo a mais para carregar. Seja receita: em uma tentativa deliberada de investigar o efeito de páginas da web lentas, a Amazon aumentou deliberadamente o carregamento da página em múltiplos de 100 ms e descobriu que as receitas dos clientes afetados geralmente caíam 1% para cada aumento de 100 ms.

Muitos outros analistas, sites e pesquisadores relataram efeitos semelhantes nas métricas de um site, seja tempo na página, taxa de rejeição, etc. Mais recentemente, o Google começou a levar em consideração a velocidade da página ao calcular a classificação da página nos resultados de pesquisa. O que parece contar é o tempo até o primeiro byte. Quanto mais tempo demorar para carregar o primeiro byte de uma página, mais severamente sua classificação de página será penalizada. Um site pode sofrer com a situação de nem ser acessado porque aparece na página três, quatro ou cinco dos resultados de pesquisa do Google.

43:00 O cache NGINX permite que você

Os recursos de cache do NGINX permitem que você melhore a experiência do usuário final reduzindo o tempo até o primeiro byte e tornando o conteúdo da web mais rápido e responsivo.

O NGINX permite que você consolide e simplifique sua infraestrutura web. O NGINX não é apenas um cache da web independente. O NGINX inclui um servidor de origem da Web, inclui um gateway direto para APIs como FastCGI e, no NGINX Plus, inclui os recursos para construir um balanceador de carga sofisticado e pronto para empresas e um controlador de entrega de aplicativos. Isso permite que você consolide vários componentes de rede diferentes em sua infraestrutura web em um único componente – NGINX ou NGINX Plus – fornecendo soluções mais confiáveis, fáceis de depurar e mais rápidas.

O NGINX permite que você aumente a capacidade do servidor retirando tarefas repetitivas dos servidores upstream. Na verdade, mesmo para conteúdo que parece não poder ser armazenado em cache (a página inicial de um site de blog, por exemplo), há mérito em armazená-lo em cache por apenas um segundo no proxy NGINX.

Quando cem usuários solicitam o mesmo conteúdo no mesmo segundo, o NGINX reduzirá isso a uma única solicitação ao servidor de origem e fornecerá conteúdo de volta para esses usuários a partir de seu cache com a promessa de que esse conteúdo nunca estará mais de um segundo desatualizado. Isso geralmente é mais do que suficiente para um site de blog ou um site semelhante, mas faz uma grande diferença no desempenho – tanto na carga nos servidores upstream quanto na despesa que você tem em gerenciar e implantar capacidade suficiente.

Por fim, não se esqueça de um dos usos estratégicos do NGINX: isolá-lo de falhas de servidores upstream por meio da capacidade de “usar obsoleto” do cache proxy. Se eles estiverem lentos, se estiverem retornando erros, se houver algum tipo de falha, o NGINX pode retornar à versão local em cache do conteúdo e continuar a usá-la até que seus servidores upstream se recuperem.

45:21 Considerações Finais

38% dos sites mais movimentados do mundo usam o NGINX predominantemente por seus recursos de aceleração da web e cache de conteúdo. [ Editor – Esta estatística foi aplicada quando o webinar foi entregue em maio de 2014; veja o valor atual aqui . ] Para mais soluções e mais detalhes, confira os blogs e os resumos de recursos em nginx.com , que falam sobre os recursos do NGINX e do NGINX Plus. E dê uma olhada em nossa lista de webinars , não apenas os futuros, mas também os que serão adicionados em breve, de eventos passados desta série.

E se você quiser investigar mais esses recursos, é claro que há documentação e soluções que você pode encontrar em nginx.org e nginx.com , mas nada supera fazer o download e experimentar. O produto de código aberto pode ser encontrado em nginx.org , ou o produto comercial com suporte, com balanceamento de carga adicional, entrega de aplicativos, gerenciamento e recursos de facilidade de uso em nginx.com .

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

Perguntas e respostas

Vamos começar a trabalhar nas perguntas e ver como nos saímos.

Solicitações de intervalo de bytes 47:20

Temos uma pergunta sobre solicitações de intervalo de bytes. Solicitações de intervalo de bytes são usadas quando um cliente solicita um pedaço de conteúdo, mas precisa apenas de um subconjunto desse conteúdo. Digamos que é um arquivo de vídeo e o cliente precisa apenas de parte do vídeo. Ou muito comumente é um arquivo PDF: o usuário leu os cabeçalhos que têm um índice no arquivo PDF, e o cliente quer apenas baixar um determinado conjunto de páginas. Como isso funciona no cache de conteúdo do NGINX?

O processo é o seguinte. Quando o NGINX recebe uma solicitação de intervalo de bytes para um recurso e todo o recurso já está no cache, o NGINX responderá do cache com o intervalo de bytes solicitado pelo cliente. Se esse recurso não estiver no cache, o NGINX fará uma solicitação de todo o recurso ao servidor upstream e armazenará esse recurso no cache. Atualmente, nesse ponto, o NGINX não obedecerá à solicitação de intervalo de bytes e retornará todo o recurso 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á para o documento inteiro de qualquer maneira e somente se esse documento for transmitido, o cliente aborta a conexão e começa a fazer solicitações de intervalo de bytes. Portanto, para conteúdo armazenado em cache, o NGINX atende às solicitações de intervalo de bytes. Para conteúdo não armazenado em cache, o NGINX recupera todo o conteúdo do servidor upstream e retorna todo o conteúdo ao cliente nessa instância.

49:13 Revalidação do Proxy Cache

Esta é uma pergunta sobre a capacidade de revalidar o cache do proxy. Esse é o recurso que permite ao NGINX fazer um GET condicional no servidor upstream para verificar se o conteúdo foi alterado. A questão é:

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

A resposta é que ele apenas verifica a data If-Modified-Since do conteúdo e, como questão de prática, geralmente é uma boa prática sempre incluir If-Modified-Since em suas respostas e tratar ETag s como opcionais, porque elas não são tratadas de forma tão consistente ou tão ampla quanto a data da "última modificação" que você tratará na resposta.

50:07 Distribuindo o cache em discos iguais

É possível que o NGINX balanceie a carga do cache de um único site entre alguns discos iguais para melhor desempenho?

Sim, é preciso um pouco de trabalho. O cenário típico é implantar vários discos sem RAID e, em seguida, implantar caches individuais, um fixado em cada disco. Requer alguma configuração adicional e particionamento do tráfego. Se você precisar de ajuda para configurar isso, entre em contato com nossa comunidade e lidaremos com sua solicitação específica lá, ou se você estiver usando o NGINX Plus, entre em contato com nossa equipe de suporte e teremos prazer em ajudar.

Cabeçalho Variável 50:50

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

Não, o NGINX não manipula automaticamente cabeçalhos Vary . Se isso for um problema, é simples 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 . Então você pode armazenar várias versões diferentes.

51:25 Primitivos de cache

Todos os primitivos e diretivas de cache estão sendo respeitados?

Em geral, sim. Há alguns casos extremos, como cabeçalhos Vary , que não são respeitados. Em muitos casos, há um grau de latitude em como vários caches interpretam os requisitos do RFC. Sempre que possível, optamos por implementações que são confiáveis, consistentes e fáceis de configurar.

51:52 Cabeçalhos e dados upstream

Os cabeçalhos e dados upstream estão sendo armazenados em cache?

Sim, eles estão. Se você receber uma resposta do cache, os cabeçalhos serão armazenados em cache, bem como o corpo da resposta.

52:13 *‑Cabeçalhos de codificação

Os valores do cabeçalho são armazenados em cache, assim como o corpo da resposta, então... Eu ficaria bastante surpreso se o NGINX não operasse corretamente com as várias combinações diferentes de Transfer-Encoding . Accept-Encoding é frequentemente implementado por meio de um cabeçalho Vary , então os comentários anteriores sobre a necessidade de colocar cabeçalhos Vary na sua chave de cache se aplicam aqui (no caso de clientes que não oferecem suporte a isso).

52:56 RÁPIDO

O cache funciona para o SPDY?

Absolutamente. Você pode pensar nisso como um proxy frontend para o NGINX, embora na prática ele esteja muito, muito profundamente interligado ao kernel do NGINX. Sim, o SPDY funciona para cache.

53:15 Cabeçalho Variável , Rodada 2

Aqui está outra pergunta sobre o cabeçalho Vary . Para confirmar, se você estiver usando respostas de cabeçalho Vary e gzips, dê uma olhada em algumas 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 na chave de cache.

53:45 Velocidade da página

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

Essa é uma pergunta que você precisa compartilhar com os desenvolvedores do PageSpeed .

54:00 Outros Caches

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

CDNs são soluções de cache de conteúdo muito eficazes. As CDNs são implantadas como um serviço; você tem controle mais limitado sobre como o conteúdo é armazenado em cache e como ele expira, mas elas são uma ferramenta muito eficaz para aproximar o conteúdo dos usuários finais. O NGINX é uma ferramenta muito eficaz para acelerar aplicativos web e, muito comumente, ambos são implantados juntos. No caso de caches autônomos como o Varnish: mais uma vez, são tecnologias muito capazes que funcionam de maneira semelhante ao NGINX em muitos aspectos. Um dos benefícios do NGINX é que ele reúne gateways de aplicativos de serviço de origem, cache e balanceamento de carga em uma única solução. Isso lhe dá uma infraestrutura mais simples e consolidada, mais fácil de implementar, mais fácil de gerenciar, mais fácil de depurar e diagnosticada se você tiver algum problema.

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

Para experimentar o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."