Cache de página inteira no CE 1.8 - Um módulo FPC Magento? Verniz? Ambos?

Por isso, estou um pouco confuso ao pesquisar sobre o Full Page Caching for Community Edition 1.8. Eu já implementei um CDN Redis Cache de dois níveis, ajustei o my.cnf do MySQL para obter o desempenho máximo (com o banco de dados em um servidor separado, é claro), e eu tenho dois servidores hospedando nossa loja atrás de um balanceador de carga. Digo isso para ressaltar que não estou pulando imediatamente para o FPC antes de fazer os ajustes iniciais de desempenho.

Eu nunca usei Varnish antes em qualquer tipo de site, muito menos em Magento, e também nunca criei um FPC no Magento. Entendo o Varnish como um proxy que atua como um cruzamento entre uma CDN e um cache de página por si próprio, enviando dados para o navegador antes que a solicitação chegue ao servidor da Web. E, no meu entender, um módulo FPC cria um cache localmente que o próprio servidor da web fornece. Eu sei que, para ambas as configurações, você precisa fazer algumas "Perfurações" para obter o conteúdo dinâmico até o navegador (embora as técnicas sejam diferentes, entre usar um módulo ou usar verniz). Por favor, corrija-me se estou entendendo algo errado aqui.

Até agora, eu pensava nelas como duas entidades separadas que você poderia implementá-lo para ajudar seu site, mas agora algumas coisas que li parecem implicar o contrário. Meu plano original era comprar o módulo " Warp Advanced Full Page Cache " para Magento (anteriormente, o "Tiny Brick Lightspeed FPC", acredito), pois parece ser o mais popular, se um toque no lado mais caro (mas, francamente , US $ 350 não é muito para nossa empresa, especialmente para o que ela pode fazer). Eu e dois de meus colegas desenvolvedores planejamos aprender a implementá-lo de maneira adequada e completa dentro de nosso próprio tema caseiro e personalizado para maximizar o que podemos obter com isso. Depois que isso foi feito, em algum momento no caminho, pensei em implementar o Varnish também - mas, como disse anteriormente, havia entendido que eles eram separados.

Agora, no entanto, estou começando a encontrar extensões como este PageCache Powered by Varnish, que é gratuito, ou esse Vortex Cache Powered by Varnish Cache, que custa quase US $ 800 USD, que são módulos do Magento Full Page Cache que funcionam diretamente com o Varnish.

Minha pergunta para você, troca de pilhas, é como eu deveria estar vendo um FPC e um verniz? Como entidades separadas? Se sim, eles são mutuamente exclusivos? Eles são dois lados da mesma moeda que eu deveria implementar juntos? Ou são semelhantes, mas nem exclusivos nem inclusivos um do outro?

Posso usar o Warp Advanced FPC que mencionei acima com o Verniz? Devo usá-lo com verniz? Ou seria melhor usar um FPC diferente se eu pretender usar o Verniz? Ou ainda mais, existe um CPF tão bom que eu não precise de verniz? Ou vice-versa, devo usar Varnish e abandonar a ideia do FPC?

Desculpem a parede de texto, mas tenho visto muitos artigos, blogs e postagens em fóruns e não consegui discernir uma resposta definitiva para essas perguntas. Eu realmente aprecio a sua ajuda e sugestões neste assunto =)

Ah, e por último, uma pergunta rápida sobre verniz e servidores da web. Atualmente, estou usando a configuração normal da pilha do Apache LAMP, mas há algum tempo eu tenho visto pessoas elogiarem o uso do Nginx com o Magento. Eu mesmo fiz alguns testes, testes de estresse e carga, e parece que ele definitivamente pode funcionar um pouco melhor nas condições certas. Como tal, eu estava pensando em mudar em algum momento no futuro próximo. Isso afetaria de alguma forma meu desejo e decisão de usar um FPC e / ou verniz?

Obrigado!!!

EDIT: Oh! E mais uma pergunta rápida: como eu tenho dois servidores hospedando meu site atrás de um balanceador de carga (que também é uma configuração que pode ser aumentada horizontalmente, se necessário), faço uso total do Redis e do Memcached hospedados em um servidor separado do Web e DB para minhas sessões e para cada nível do cache de dois níveis do Magento (bem, do Zend). Presumo que o FPC armazene seus dados em um desses sistemas? Eu precisaria ter uma extensão específica para armazená-la lá ou todos eles fazem isso? E embora eu assuma que não, isso afetaria o Verniz de qualquer maneira? Obrigado novamente!!

Há duas coisas difíceis na ciência da computação:

1. Nomeando coisas
2. Invalidação de cache.

Perfuração cai na categoria # 2 :)

Geral

A melhor abordagem é começar nos pontos mais baixos da pilha e otimizar até o front-end do Magento.

Banco de Dados e Sistema de Arquivos

Devem sempre ser as primeiras áreas a focar. Porque. E / S.

MyTop é um prático script perl baseado em Linux que imitará o comando 'top' do Linux e fornecerá informações sobre o estado de suas instâncias do MySQL.

• https://github.com/jzawodn/mytop

Htop é uma parte superior mais robusta . O recurso strace pode ajudar a determinar entradas / saídas de um processo para encontrar possíveis gargalos.

• https://github.com/hishamhm/htop

Iotop é outra ferramenta a considerar no monitoramento de E / S.

• http://guichaz.free.fr/iotop/

Outros scripts úteis como mysqltuner.pl e mysql tunning primer podem oferecer informações sobre as variáveis ​​de tempo de execução do MySQL e oferecer conselhos para ajudar. Lembre-se de que eles devem ser guias, pois a melhor abordagem é sempre uma avaliação de requisitos e ajustes com base em dados conhecidos coletados. Fazer isso às cegas pode causar mais danos às vezes do que bons. E executá-los prematuramente sem pelo menos 24 horas de variáveis ​​de tempo de execução do mysql pode oferecer maus conselhos.

• http://mysqltuner.pl
• https://launchpad.net/mysql-tuning-primer

Lembre-se de que o Percona , o MariaDB e o MySQL padrão devem funcionar com todos os itens acima. Favorecendo o Percona como um fork do MySQL, já que o Magento é muito pesado no InnoDB e o XtraDB oferece muitas ferramentas e aprimoramentos para o mecanismo db.

• http://www.percona.com/software
• https://mariadb.org/en/about/

Apache ou Nginx

Ainda usando o Apache, pois serviu muitos outros bem, inclusive eu. Eu usei e configurei o Nginx também. Embora ofereça algumas vantagens, há uma curva de aprendizado. Embora as duas sejam opções populares, ela oferece algumas vantagens sobre o Apache, uma seria uma pegada de memória menor. No entanto, um Apache compacto e rodando PHP-FPM terá uma pegada de memória semelhante.

• http://arstechnica.com/business/2011/11/a-faster-web-server-ripping-out-apache-for-nginx

Caso em questão:

Como este artigo foi sobre desempenho, devo salientar que uma das maneiras mais fáceis de ajudar o apache a sair do seu caminho é não usar arquivos .htaccess. Coloque o que você colocou lá nas estrofes do Diretório, defina AllowOverride como "None" e você não solicitará ao apache que percorra todo o caminho do documento para descobrir se ele precisa prestar atenção ao .htaccess ou não. Essa é uma dica de ajuste básica e simples que muitas pessoas parecem sentir falta.

Para ajudar a facilitar esse check-out:

• https://github.com/preinheimer/htaccessConverter

A utilização de uma CDN para ajudar a diminuir a facilidade de ambos ajudará obviamente, mas terá benefícios adicionais na otimização de front-end, pois a maioria dos navegadores de usuários finais poderá se conectar aos dois servidores com o mesmo número de limites de conexão. Isso também libera o Apache de não ter que passar por verificações e servir apenas uma imagem estática simples. O Lighthttpd é uma opção se você deseja executar um servidor da Web estático apenas para conteúdo além de uma CDN.

PHP

PHP-FPM e APC. Use-os, retire quaisquer módulos PHP desnecessários ou não necessários não necessários para o Magento.

Magento codebase

AOE_TemplateHints é ótimo para determinar se seus blocos estão sendo armazenados em cache corretamente:

• https://github.com/fbrnc/Aoe_TemplateHints
• http://www.fabrizio-branca.de/magento-advanced-template-hints-20.html

AOE_Profiler é bom para criação de perfil, certifique-se de ativar sua criação de perfil de camada de banco de dados (em um ambiente local / dev, obviamente). Isso, em conjunto com a ferramenta mytop mencionada anteriormente, facilita a localização de SQL com mau comportamento.

• https://github.com/fbrnc/Aoe_Profiler

Módulos de terceiros e código personalizado

Algumas boas práticas de otimização do Magento são uma boa leitura e lembre-se de revisar os módulos de terceiros antes de usá-los. (existem muitos IMO que se comportam mal).

• http://info.magento.com/rs/magentocommerce/images/Conquer_the_5_Most_Common_Magento_Coding_Issues_to_Optimize_Your_Site_for_Performance.pdf

Uma ferramenta Magniffer do Magento ECG ajudará a identificar facilmente o código de mau comportamento com base no PDF fornecido acima. Ele é baseado no symfony / php-parser, mas pode ser instalado via compositor.

• https://github.com/magento-ecg/magniffer

Verniz

Como um defensor de Varnish, o autor era um desenvolvedor de kernel do FreeBSD, ele oferece alguns tempos de carregamento sub-segundos loucos. No entanto, se você tem algumas das menores diferenças em seus modelos que não estão prontas para uso, você gastará tempo configurando verniz / magento para perfurar o conteúdo de que precisa. A maioria dos que eu vi simplesmente AJAX'ify os itens necessários não armazenados em cache do Varnish.

Existem vários módulos Magento para ajudar a facilitar essa perfuração e armazenamento em cache:

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Aguarrás Nexcess: https://github.com/nexcess/magento-turpentine

Em última análise, isso deve ser no final da sua jornada de otimização, e PODE exigir alguma personalização para fazer as coisas direito.

Magento CE FPC

Até agora, o melhor CE FPC que encontrei é: Lesti :: FPC

é um FPC muito bem organizado (baseado em todos os observadores) de código aberto e gratuito para a Comunidade.

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (github em caso de link futuro morto)

No final do dia, use seu próprio teste e julgamento.

Algumas leituras adicionais:

• http://www.kingletas.com/2012/08/caching-performance-optimization.html
• https://www.sonassi.com/knowledge-base/magento-with-varnish/
• http://info.magento.com/rs/magentocommerce/images/HostandBoastBestPracticesForMagentoHosting.pdf

Sei um pouco tarde para esse segmento, mas se você ainda estiver procurando uma solução, poderá considerar o Evolved Caching . É o mesmo preço do Warp, mas:

• É muito rápido e fácil de instalar e configurar - todas as perfurações e configurações são feitas de dentro do admin
• Integra-se diretamente ao Varnish e permite limpar e aquecer o cache do Varnish a partir do Magento
• Funciona com o front-end form_key introduzido no 1.8 CE no Varnish e em seu próprio cache.
• É desenvolvido ativamente com suporte responsivo. Novas versões regulares com o objetivo de liberar correções de erros dentro de alguns dias após o relatório
• Possui extensa documentação que é atualizada a cada versão

A configuração do Varnish é simples, basta ativar uma configuração de administrador e usar o .vcl encontrado aqui . Você também não está restrito ao Varnish, que só serve cache quando não há cookies, conforme o normal - você obtém uma taxa de acertos no cache muito alta.

Escrevemos um FPC compatível com a nova chave de formulário do Magento 1.8. Cache de página inteira de Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html

O BOOMER faz um ótimo ponto sobre começar com pouco stack e subir o seu caminho. Um FPC ou verniz deve ser o último que você faz. Fazemos auditorias de desempenho e geralmente encontramos problemas com as configurações MySQL e APC que estão realmente desativadas. Como os tamanhos de buffer do Innodb, definidos como padrão e o banco de dados cresceu muito além dele.

Recomendamos não usar qualquer FPC com verniz, a menos que especificamente projetado para trabalhar em conjunto. Geralmente, não recomendamos o Varnish, a menos que você tenha um punhado de servidores robustos que foram ajustados com sua base de código e ainda estão lutando para manter o tráfego. Atualizar conteúdo dinâmico pode ser complicado com o Varnish especificamente ao tentar limitar suas solicitações ao back-end do Magento e, por sua vez, reduzir a carga. Se você tiver uma ou duas cabeças da web, os ganhos podem não valer o tempo e a complicação.

Na maioria das situações, um bom FPC fornecerá o desempenho que você precisa, é claro após o ajuste do servidor e da base de código. Com nosso FPC, você pode obter tempos de geração abaixo de 15ms no cache de nível 1 e abaixo de 100ms no cache padrão. Nosso cache de nível 1 é usado para casos em que o usuário não está logado e não possui nada no carrinho, pois não realiza perfuração. Quando uma dessas condições é falsa, o cache padrão é usado com o suporte completo de perfuração.

Nosso FPC possui perfuração fácil embutida e funciona fora da caixa com todos os blocos Magento padrão, bem como quaisquer blocos personalizados que você possa ter. Tudo é configurável através do painel de administração.

Eu recomendo ficar com o Redis, a menos que você esteja tendo problemas de dimensionamento. Ele possui suporte a tags e é muito mais rápido que o memcached com arquivo ou banco de dados como back-end lento. Se você deseja tags e limpeza consistentes, use o memcached com o banco de dados quando tiver várias cabeças da web. Com o suporte de tags do Redis integrado, você não precisa se preocupar com isso. Você também pode usar o Redis para suas sessões.

Eu posso falar por todos os FPCs, mas com o nosso, você pode configurar através do administrador onde armazená-lo. Você pode optar por usar o back-end padrão do cache do Magento ou especificar configurações personalizadas para usar Arquivo, Banco de Dados, APC, Redis, Memcache e um back-end de Arquivo Otimizado.

Não há resposta correta. Uma loja deve ter carregamentos de página dinâmicos abaixo de 3s e idealmente 1-2s de carregamentos de páginas dinâmicos, não é necessário um segundo de segundo e é principalmente uma estatística orientada a marketing. O Apache é fácil de aprender e difícil de executar; o Nginx é difícil de aprender e fácil de executar; muitos sites estão migrando para o Nginx; no entanto, não é simples ter uma arquitetura de alta qualidade baseada no Nginx e no Magento.

Os clusters Magento para vários servidores já são complexos de implementar e, ainda mais difíceis de manter, se não estiverem na arquitetura correta, normalmente trabalhamos com clusters maiores, o que faz com que tudo corra mais suavemente, incluindo a classificação. Fazemos isso com a configuração padrão da instalação, com pequenas alterações para estabilidade de médio a longo prazo, visando o carregamento dinâmico de páginas 1-2s, simplificando muito a manutenção.

O verniz pode ser um CPF, CDN, entre outros, no entanto, no seu caso, é melhor pensar nele como um CPF. Um FPC permite mais visitantes no servidor e fornece uma entrega estática mais rápida da qual o Varnish é uma dessas ferramentas, no entanto, existem vários problemas, incluindo conteúdo dinâmico, controle de estoque, preços. A resposta se resume a como sua empresa está estruturada, como seus dados são carregados, com que frequência, seu tipo de hospedagem e mais, simplesmente afetam seus negócios ao fornecer conteúdo estático aos visitantes. Tecnicamente, você pode mitigar muito disso com a configuração do FPC, mas isso complica o ambiente de negócios, do ponto de vista do proprietário da empresa, pode não produzir um retorno equilibrado do investimento.

O FPC é a última parte, se você tiver sub-3s ou carregamento dinâmico melhor, sua arquitetura pode lidar com a solicitude dos visitantes, pois isso afeta a classificação, absorve os picos de marketing e feriados e tem o orçamento para adicionar complexidade à arquitetura do servidor - a hospedagem deve ser de 0,5 -1% da receita para empresas menores, a maioria é executada substancialmente com isso, causando muitos problemas de negócios indiretos.

O motivo pelo qual você não encontrou uma resposta definitiva deve-se ao fato de essas perguntas levarem meses para serem respondidas, pois são qualitativas (baseadas nos negócios) e requerem informações que uma empresa não gostaria de publicar publicamente, as velocidades de carregamento da página são quantitativas (baseadas nas técnicas) ) que pode ser publicado publicamente, é como você combina os dois que cria a solução.

Você pode usar esse cache de página do Magento que atenderá às suas necessidades e é semelhante ao verniz. É usado por muitas das maiores lojas Magento. Algumas funcionalidades:

1. Como o Varnish, ele não utiliza uma conexão com o banco de dados para 90% das solicitações. Como resultado, é extremamente rápido
2. Ele tem capacidade de liberar páginas automaticamente quando coisas como inventário de produtos são alteradas e é muito bom nisso
3. Como um cache de várias camadas, também suporta perfuração quando o usuário faz login (essas solicitações exigem o uso do banco de dados)

Como um cache de vários níveis, é escalável até mesmo para os armazenamentos de tráfego mais alto e tem sido usado em muitos sites de tráfego extremamente alto que recebem tráfego de pico, como as lojas que aparecem no SharkTank (programa de TV)