TL; DR - No MageStack, usamos Varnish, Redis (cache), Redis (sessões) e Eaccelerator / Zend OPCache (dependendo da versão do PHP)
Você já entendeu a maior parte.
O back-end do cache, o armazenamento da sessão, o cache do código de operação, o cache da página inteira e o proxy reverso são todos completamente diferentes.
Você pode usar diferentes tecnologias para todos e usá-las TODAS simultaneamente (incluindo verniz e um FPC)
Back-ends de cache
- Arquivos (Núcleo) Padrão
- Memcache (Core)
- APC (Core)
- Redis (módulo <1,9 cortesia de Colin Mollenhour)
- MongoDB (módulo cortesia de Colin Mollenhour)
- Rubic (módulo cortesia de Daniel Sloof)
Você pode usar apenas um back-end de cache.
Ao contrário da crença popular, o uso de um cache baseado em memória não melhorará o desempenho. Mas ele superará algumas falhas fatais no cache padrão do Magento, com base em arquivos.
Ao escrever esta mensagem, Redis é minha recomendação.
Armazenamentos de sessões
- Arquivos (Núcleo) Padrão
- Memcache (Core)
- Redis (módulo <1,9 cortesia de Colin Mollenhour)
- MongoDB (módulo cortesia de Colin Mollenhour)
Você pode usar apenas um armazenamento de sessão.
Ao contrário da crença popular, o uso de um armazenamento de sessão baseado em memória não melhorará o desempenho.
Ao escrever esta mensagem, Redis é minha recomendação.
Cache do OpCode
- APC
- XCache
- Acelerador (PHP <5.4)
- Zend OPCache (PHP> 5.4)
Na verdade, você pode instalar vários caches de código de operação, mas isso não é recomendado, nem eu esperaria obter ganhos.
Minhas recomendações estão entre parênteses acima.
Não é necessário instalar nenhum módulo para alavancar isso.
Cache de proxy reverso
- Verniz
- Nginx
- Apache
- … e muitos mais
Você pode usar vários proxies reversos e, embora isso seja complexo e propenso ao alongamento do cache, ele pode ter méritos (por exemplo, para evitar a estampagem durante a liberação do cache).
Use um quando necessário (ou seja, não para acelerar um site lento, mas para reduzir o uso de recursos em um site rápido).
Para alavancar um proxy reverso, ele precisa do lado do servidor habilitado e precisa de um módulo para o Magento.
O motivo do módulo é ajudar a controlar a lógica de armazenamento em cache (por exemplo, para informar ao cache o que ele deve e não deve armazenar em cache) e também para gerenciar o conteúdo do cache (ou seja, para acionar limpezas do cache).
Eu não recomendo, a menos que você tenha uma compreensão total do que está fazendo. Os proxies reversos configurados incorretamente podem interromper as informações do cabeçalho, causar perda de sessão, compartilhamento de sessão, conteúdo obsoleto, aplicar limites adicionais ao tempo de carregamento / buffers, consumir recursos adicionais etc.
Cache de página inteira
- EE FPC
- ... muitos outros (via módulos)
Use um quando necessário (ou seja, não para acelerar um site lento, mas para reduzir o uso de recursos em um site rápido).
Ao contrário da crença popular, você pode (e deve) usar um FPC em conjunto com um cache proxy reverso. Os dois resolvem problemas diferentes e têm capacidades diferentes.
Os FPCs podem alavancar mais inteligência, porque têm acesso direto à sessão dos usuários e ao núcleo do Magento, enquanto um proxy reverso não tem conhecimento de aplicativos (é bastante idiota na maneira como funciona) - então os dois se complementam, não competem entre si .
Ou seja. Não pense em verniz ou FPC, pense em verniz e FPC.