Muito foi dito recentemente sobre os méritos de sites estáticos . Mas em muitas situações, uma abordagem dinâmica é uma necessidade. Seja um sistema de gerenciamento de conteúdo, uma ferramenta de relacionamento com o cliente ou uma loja on-line, eles permitem que os usuários finais mantenham sites complexos de maneira rápida e consistente. E quando montados corretamente, eles podem competir com sites estáticos por velocidade.
qualquer aplicativo que precise ler e gravar dados com frequência causará um atraso perceptível
Qualquer que seja o sistema que você use, os sites dinâmicos normalmente são compostos por elementos semelhantes. Estas são uma forma de servidor web, um backend e uma aplicação, escritas em uma ou mais linguagens de programação. Essa combinação de componentes oferece muita flexibilidade, mas cada um contribui com sua própria sobrecarga e aumenta o tempo de carregamento, algo que todos os sites modernos querem evitar. Isso é especialmente verdadeiro com o acesso ao banco de dados: qualquer aplicativo que precise ler e gravar dados com frequência causará um atraso considerável.
Isto onde o cache e uma estratégia de cache apropriada para o seu caso de uso ajudará. O objetivo básico do armazenamento em cache é evitar chamadas desnecessariamente freqüentes entre as camadas do banco de dados do aplicativo e, em vez disso, usar páginas HTML estáticas pré-geradas, que são muito mais rápidas para renderizar em um navegador.
O primeiro cache que qualquer usuário da web teria notado é o cache em seu navegador. Quantas vezes os desenvolvedores solicitaram que você fizesse uma "atualização forçada" para ver as alterações? Caches do navegador são simples, mas um bom ponto de partida para começar a explicar os conceitos de armazenamento em cache. Um navegador armazena representações de páginas da Web visitadas no computador de um usuário, normalmente atualizando-as uma vez por sessão se as alterações forem detectadas ou forçadas pelo site.
Uma ferramenta comum usada por proprietários e administradores de sites é um 'cache de proxy reverso' que fica entre solicitações de páginas feitas por um navegador da Web e pelo aplicativo da Web. Ele intercepta solicitações e processa cópias de páginas diretamente do cache, proporcionando um aumento de velocidade notável.
Existem várias opções principais de cache de proxy disponíveis para auto-instalação ou como "Software as a Service". (Estamos ignorando os provedores de hospedagem em nuvem que geralmente empacotam tudo o que você pode precisar em uma pilha da web autocontida.)
As opções populares de cache de proxy incluem:
As opções SaaS para armazenamento em cache geralmente estão no mundo das Content Delivery Networks (CDNs), que, em vez de colocar um cache entre um usuário e uma pilha da Web, servem aos usuários conjuntos de conteúdo em cache geograficamente mais próximos a eles. É uma diferença sutil, mas que, para sites grandes com públicos globais, pode fazer uma diferença significativa.
Verniz está disponível em todos os gerenciadores de pacotes do Linux, como uma imagem do Docker e muitas outras página de instalação do projeto para mais detalhes.
O verniz armazena um arquivo de configuração padrão em /usr/local/etc/varnish/default.vcl ou /etc/varnish/default.vcl , escrito em VCL (Linguagem de Configuração do Verniz). Este arquivo de configuração é compilado em um pequeno programa através de um interpretador C para aumentar ainda mais a velocidade.
Dependendo de como você instalou o Varnish, o arquivo de configuração será parecido com isto:
backend default {.host = "127.0.0.1";.port = "8000";}Na sua forma mais simples, isso define o backend padrão usado pelo Varnish, definindo o host e a porta que ele deve ouvir e interceptar o conteúdo.
Um recurso útil do verniz é verificar em intervalos predefinidos se um back-end ainda está saudável. É chamado de 'Backend Polling' e é configurado adicionando uma seção de teste na declaração de backend:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}As configurações padrão fornecidas pelo Verniz são fornecidas acima e informam para visitar um intervalo .url every. Particular e que, se pelo menos .threshold for inferior a probes .window , a URL responderá dentro de milissegundos .timeout , o backend ainda é considerado saudável. Uma vez considerado 'não íntegro', o conteúdo é servido a partir do cache por um período pré-definido.
Abordaremos alterações específicas na configuração do Varnish sob cada opção de plataforma, por enquanto, vamos dar uma olhada nas opções gerais.
Portos
Inicialmente, a porta do seu servidor da Web precisará ser alterada do padrão. Por exemplo, na configuração do Apache Vhost, altere a porta para 81 ou 8080.
Inicie o daemon Varnish com o comando verniz ou usando um wrapper de serviço. O daemon tem opções de sinalização, sendo as mais comuns e úteis:
Verificando tudo está funcionando
Execute o comando varnishstat ou visite isvarnishworking.com para verificar se o seu servidor Varnish está pronto e ouvindo as solicitações.
O que não fazer cache
Há certas partes de um site que não queremos armazenar em cache, por exemplo, as páginas de administração. Podemos excluí-los criando uma sub-rotina vcl_recv no arquivo default.vcl contendo uma instrução if que define o que não deve ser armazenado em cache:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Se você estiver usando o Varnish 4, as coisas são um pouco diferentes, incluindo valores de retorno. A função vcl_recv agora retorna um valor ahash em vez de uma pesquisa.
sub vcl_recv {...return(hash);}É também aqui que definimos sites ou subdomínios que o Varnish deve ignorar, adicionando um req.http.host ~ 'example.com' à declaração if .
Biscoitos
Por padrão, o Varnish não armazenará em cache o conteúdo do back-end que define os cookies. Da mesma forma, se o cliente enviar um cookie, ele ignorará o Verniz diretamente no backend.
Os cookies são usados com frequência por sites para rastrear a atividade do usuário e armazenar valores específicos do usuário. Geralmente, esses cookies são de interesse apenas para o código do lado do cliente e não são de interesse do backend ou do verniz. Podemos dizer ao Varnish para ignorar cookies, exceto em áreas específicas do site:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Esta declaração if ignora os cookies, a menos que estejamos na área de administração do site, onde a passagem de cookies pode ser mais útil (a menos que você realmente queira frustrar os administradores do site).
Outras exceções
Com uma instalação padrão, o Varnish também não armazena em cache páginas protegidas por senha, solicitações GET e HEAD.
Vamos agora olhar para dois casos de uso perfeitos para o Verniz: Drupal e Magento. Ambos são sistemas altamente dinâmicos que permitem que usuários não técnicos realizem uma ampla variedade de tarefas complexas. Isso pode levar a carregamentos de página com muita consulta de banco de dados e sites ocupados ficarão notavelmente lentos. As páginas típicas criadas com esses sistemas terão uma mistura de conteúdo atualizada com pouca frequência e com frequência.
O Drupal possui opções de cache padrão que executam funções semelhantes ao Varnish, mas não fornecem a flexibilidade ou a velocidade de aumento requerida por sites maiores ou mais complexos.
Na verdadeira maneira Drupal há um módulo para lidar com integração de verniz para salvar algumas das configurações manuais descritas acima.
Instale o módulo e certifique-se de seguir as instruções de instalação incluídas no arquivo Leiame do módulo.
Certifique-se de que o arquivo / etc / default / verniz tenha as seguintes opções de daemon definidas (e o recuo é importante):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Certifique-se de que o Apache e quaisquer hosts virtuais associados estejam atendendo na porta 8080, não 80. Reinicie os dois serviços depois de fazer essas alterações.
Pode ser necessário definir uma 'Chave de controle de verniz' na página de configuração do módulo. Descubra o que é essa chave com o comando cat / etc / verniz / secret e cole-a na página de configurações. Selecione a versão correta do Varnish, salve as configurações e você verá uma série de marcas verdes na parte inferior da página.
O módulo Varnish interage com as configurações padrão do cache do Drupal, portanto, verifique se você ativou e configurou o seu caso de uso.
Execute o varnishstat a partir da linha de comando, comece a navegar pelo site como um usuário anônimo e você deverá ver as estatísticas mudando na saída do comando.
Um dos caminhos que não queremos armazenar em cache no Drupal são as páginas de administração, podemos fazer isso com uma sub-rotina vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}Você pode considerar não colocar em cache as páginas do usuário (logadas), as páginas de atualização do sistema e outras páginas geradas por módulos altamente dinâmicos, como sinalizadores que fazem uso extensivo do ajax para funcionar. Faça isso adicionando mais parâmetros req.url à instrução if .
Uma instalação padrão do Magento vem com um sistema de cache interno que armazena versões estáticas dos elementos do site em uma pasta especificada. A página Sistema -> Gerenciamento de Cache fornece uma visão geral do status atual do cache, além de permitir que você limpe todos os caches de componentes individuais. Você pode limpar arquivos CSS e JS agregados e arquivos de imagem gerados automaticamente desta página.
A próxima versão 2 do Magento suportará o armazenamento em cache do Varnish por padrão, mas por enquanto precisamos usar plugins de terceiros, eu recomendo o Módulo de terebintina . Certifique-se de ler o arquivo leia-me do projeto Como ele observa algumas etapas extras de configuração, ignorá-las pode danificar seu site.
O módulo de terebintina é altamente configurável e fará as alterações necessárias nos arquivos vcl e na configuração do Varnish para você. Algumas opções importantes para definir são:
O módulo de terebintina vincula-se ao cache padrão do Magento, portanto, limpar os caches na página de cache do Varnish limpará os caches relevantes do Varnish.
Além de usar o Varnish com qualquer um dos sistemas dinâmicos acima, aqui estão algumas dicas diversas que ajudarão no cache de qualquer site.
Se você estiver veiculando o mesmo conteúdo em contextos diferentes, ele deverá usar o mesmo URL. Por exemplo, não misture o uso de article.html , article.htm e artigo , embora seu CMS possa permitir isso. Isso levará a três versões diferentes em cache do mesmo conteúdo.
Como vimos acima, os cookies são difíceis de armazenar em cache e raramente são tão necessários quanto pensamos. Tente limitar seu uso e número para páginas dinâmicas.
Carregar recursos do site pode ser uma das partes mais demoradas de uma renderização de página e há dicas simples para reduzir esse fardo:
O uso de sprites CSS Image para iconografia em vez de vários arquivos pequenos resulta em menos tráfego na rede.
Hospedar bibliotecas CSS e JavaScript localmente significa menos tráfego de rede e mais controle sobre as estratégias de armazenamento em cache. Isso pode significar um aumento na sobrecarga de manutenção para manter esses ativos atualizados. Armazene esses ativos em pastas com nomes consistentes, para que referências a eles também possam ser consistentes.
Espero que esta introdução para acelerar seus sites dinâmicos com cache seja útil. O ganho de desempenho vale um período inicial de configuração, experimentação e ajustes. Nesta era de períodos curtos de atenção e impaciência, qualquer ganho de velocidade que você possa obter da sua configuração fará a diferença para seus usuários e para a concorrência.
Imagem em destaque, imagem de cache de rede via Shutterstock.