O verniz é ideal para você?
O verniz não é o desempenho definitivo do Magento. É ótimo compensar a carga de bots e vitrines - mas não deve ser sua primeira porta de escala para tornar sua loja mais rápida.
De fato, a implementação do Varnish deve ser a última modificação de desempenho em sua loja. Somente solte-o quando estiver vendo os tempos de carregamento da página que o Magento é capaz de fornecer sem ele (por exemplo, <600ms de carregamento da página).
Sua loja ainda precisa ser rápida
Como o Varnish ainda exige pelo menos um único carregamento de página para preparar o cache, isso significa que seu desempenho não armazenado em cache ainda precisa ser muito bom. A grande maioria dos URLs únicos (hits de navegação em camadas, consultas de pesquisa etc.) nunca acabará sendo veiculada pelo Varnish, a menos que:
a) Seus TTLs são tão altos que uma consulta de pesquisa de 4 dias atrás ainda é válida hoje
b) A presença no site é tão vasta que os URLs são preenchidos em um período muito curto de tempo
Você também deve considerar que nem todas as lojas se prestam ao verniz . Qualquer site que incentive os usuários a criar uma sessão pessoal (por exemplo, faça login, adicione ao carrinho etc.) no início da jornada do cliente significa que o Varnish será redundante.
Por exemplo, sites de compras particulares incentivam o login do usuário no local, no entanto, ao fazer isso, significa que o Varnish nunca realmente possui conteúdo não exclusivo que pode armazenar em cache. Portanto, suas taxas de acerto serão drasticamente baixas e não haverá nenhum benefício em usar o Varnish.
Conteúdo novo ou taxas de acerto mais altas
Imagem cortesia de magestack.com
Usar o Varnish de maneira eficaz é encontrar um equilíbrio entre o conteúdo obsoleto e a quantidade de visitantes em seu site.
Se você tem um site ocupado - é provável que você consiga sair com TTLs mais baixos e ainda tenha uma alta taxa de acerto de verniz - e também continue a ter TTLs baixos - assim, com conteúdo mais atualizado. Portanto, suas alterações de estoque / preço são refletidas rapidamente e o cache é continuamente preparado a partir do volume de passos.
Se você possui um site de baixo tráfego, precisará fazer um compromisso. Aumente seus TTLs para garantir uma taxa de acerto mais alta - ou tenha conteúdo atualizado. Você não pode ter os dois. Sim, você pode executar uma ferramenta de rastreamento / spider continuamente - mas os recursos que isso consumiria e o grande volume ou URLs que podem ser rastreados (geralmente na casa das dezenas de milhares de lojas pequenas ) significa que isso simplesmente não é eficaz. Geralmente, lojas menores se beneficiariam mais de uma boa extensão FPC e de uma configuração de servidor altamente otimizada.
Mas é claro que posso usar o Varnish mesmo quando os usuários estão conectados, e quanto ao cache por usuário ou ESIs?
ESIs
Os ESIs são um excelente utilitário para manter o conteúdo no cache e ainda ter blocos dinâmicos na página. Mas, para ser usado com eficiência, você precisa minimizar a quantidade de retornos de chamada ao mínimo. Há um pequeno módulo inicial que você pode usar como base para esse processo - apenas certifique-se de apertar as brechas de segurança nele, é muito inseguro por padrão - não há restrições quanto ao layout do manipulador que você pode / não pode carregar
Cada vez que o bootstrap do Magento é carregado, ele atinge uma penalidade de desempenho de cerca de 200ms - antes mesmo de carregar uma coleção / renderizar um bloco etc. Portanto, se você tiver mais de 3x ESIs, é provável que você tenha acabado com tempos de carregamento de página mais lentos usando Varnish + ESIs para conteúdo dinâmico, do que apenas ignorar o Varnish e passar a solicitação diretamente para o próprio Magento.
Então, para realmente usar os ESIs de maneira eficaz, você precisa combinar várias solicitações em uma única solicitação.
Por exemplo, uma página de exibição de categoria que lista 20 produtos precisa mostrar níveis de estoque precisos. Então você usa ESI para cada bloco na página. Seriam 20x solicitações de estoque ESI. Embora as solicitações de estoque sejam muito leves, a execução de 20x delas simultaneamente prejudicaria o desempenho. Em vez disso, você pode atender a todo o bloco / coleção de 20 produtos e receber essa solicitação 1x. Mas carregar e renderizar a coleção é provavelmente o elemento mais lento da página, então você não ganhou muito.
O uso do ESI precisa efetivamente de planejamento e execução adequados, ou você terá um site mais lento do que não usar o Varnish.
Cache por usuário
Depois, há a alternativa de usar um cache específico do usuário. Essa é uma péssima idéia, a menos que você tenha um site com pouco tráfego. Sua taxa de acertos será terrivelmente baixa - pois as chances de um visitante acessar a mesma página em que eles já foram são muito baixas. E para cada cliente, essa página de 6 KB estará ocupando cada vez mais espaço na sua lixeira de verniz.
Por exemplo, se você alocou 1 GB ao Varnish. Em um site típico em que os usuários visualizam 8 páginas por visita, em média 6 dessas páginas serão únicas. São 28 visitantes por 1 MB de armazenamento. Em seguida, considere suas imagens, CSS e JS - estas (felizmente) serão comuns, mas ainda assim provavelmente ocuparão uma boa quantidade de 7-800 MB de seu armazenamento disponível. Isso deixa 200 MB de armazenamento restante, cache suficiente para 5.600 visitantes únicos.
Bem, eu não ligo, eu só quero verniz
Ok, você precisará fazer o seguinte:
- Instale um terminador SSL para ficar em frente ao Varnish (por exemplo, stud / pound / nginx)
- Instale o verniz no servidor
- Certifique-se de configurar
X-Forwarded-Forcorretamente
- Instale um módulo de verniz na sua loja
- Configure suas VCLs de verniz para excluir extensões de terceiros
Como os três primeiros pontos estão além do escopo desta resposta, deixarei isso para você. O ponto 4 é brincadeira de criança e, com o ponto 5 - continue lendo.
O mais importante sobre a implementação do Varnish é garantir que você nunca armazene em cache o conteúdo que nunca deve ser armazenado em cache.
Por exemplo.
- Retornos de chamada do gateway de pagamento
- Visão geral do carrinho
- Visão geral da minha conta do cliente
- Caixa (e respectivas chamadas Ajax)
etc.
Para os principais URLs do Magento, há uma lista bastante padrão de URIs que você pode escapar no Varnish:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Mas você também precisa considerar as extensões personalizadas / de terceiros em execução que possuem rotas, roteadores e namespaces personalizados. Infelizmente, não há uma maneira fácil de saber quais URLs dessas extensões podem e não podem ser armazenados em cache. Portanto, você precisa avaliar cada caso a caso.
Como regra, sempre que estivermos configurando o Varnish, começaremos identificando as respectivas rotas, roteadores e namespaces que eles podem ocupar e partir daí. Fazemos isso via SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Isso não fornecerá uma lista definitiva de URLs, mas quase certamente fornecerá uma entrada para você.
Não podemos enfatizar o quão importante é nunca armazenar em cache conteúdo que não deveria ser armazenado em cache. Os resultados podem ser catastróficos.
Em suma
Como em qualquer outra otimização de desempenho do servidor Magento, implementado e ajustado corretamente, pode realmente trazer benefícios. Porém, simplesmente deixar o software sem configurá-lo adequadamente não apenas tornará sua loja mais rápida, mas também potencialmente mais lenta, mais insegura e menos confiável.