TL; DR : en MageStack utilizamos Varnish, Redis (caché), Redis (sesiones) y Eaccelerator / Zend OPCache (según la versión de PHP)
Ya has entendido la mayor parte.
El backend de caché, el almacén de sesión, el caché de código operativo, el caché de página completa y el caché de proxy inverso son completamente diferentes.
Puede usar diferentes tecnologías para todos y puede usar TODOS simultáneamente (incluido Varnish y un FPC)
Backends de caché
- Archivos (Core) Predeterminado
- Memcache (núcleo)
- APC (núcleo)
- Redis (módulo <1.9 cortesía de Colin Mollenhour)
- MongoDB (módulo cortesía de Colin Mollenhour)
- Rubic (módulo cortesía de Daniel Sloof)
Solo puede usar un backend de caché.
Contrariamente a la creencia popular, el uso de una memoria caché basada en memoria no mejorará el rendimiento. Pero superará algunos defectos fatales en el almacenamiento en caché basado en archivos predeterminados de Magento.
Al escribir este mensaje, Redis es mi recomendación.
Tiendas de sesiones
- Archivos (Core) Predeterminado
- Memcache (núcleo)
- Redis (módulo <1.9 cortesía de Colin Mollenhour)
- MongoDB (módulo cortesía de Colin Mollenhour)
Solo puede usar una tienda de sesión.
Contrariamente a la creencia popular, el uso de una tienda de sesión basada en memoria no mejorará el rendimiento.
Al escribir este mensaje, Redis es mi recomendación.
OpCode Cache
- APC
- XCache
- Acelerador (PHP <5.4)
- Zend OPCache (PHP> 5.4)
En realidad, puede instalar múltiples cachés de código de operación, pero no se recomienda, ni esperaría ver ninguna ganancia.
Mis recomendaciones están entre paréntesis.
No se requiere instalar ningún módulo para aprovechar esto.
Caché de proxy inverso
- Barniz
- Nginx
- apache
- … y muchos más
Puede usar múltiples servidores proxy inversos, y si bien hacerlo es complejo y propenso a la elongación de la memoria caché, puede tener ventajas (es decir, para evitar el estampado durante una descarga de memoria caché).
Use uno cuando sea necesario (es decir, no para acelerar un sitio lento, sino para reducir el uso de recursos en un sitio rápido).
Para aprovechar un proxy inverso, necesita habilitar el lado del servidor y necesita un módulo para Magento.
El motivo del módulo es ayudar a controlar la lógica de almacenamiento en caché (es decir, decirle a la memoria caché lo que debe y no debe almacenar en memoria caché) y también administrar el contenido de la memoria caché (es decir, activar las purgas de la memoria caché).
No recomiendo ninguno a menos que tenga una comprensión total de lo que está haciendo. Los servidores proxy mal configurados pueden romper la información del encabezado, causar pérdida de sesión, compartir sesiones, contenido obsoleto, aplicar límites adicionales al tiempo de carga / almacenamientos intermedios, consumir recursos adicionales, etc.
Caché de página completa
- EE FPC
- ... muchos otros (a través de módulos)
Use uno cuando sea necesario (es decir, no para acelerar un sitio lento, sino para reducir el uso de recursos en un sitio rápido).
Contrariamente a la creencia popular, puede (y debe) usar un FPC junto con un caché de proxy inverso. Los dos resuelven problemas diferentes y tienen capacidades diferentes.
Los FPC pueden aprovechar más inteligencia, porque tienen acceso directo a la sesión de los usuarios y al núcleo de Magento, mientras que un proxy inverso no es consciente de la aplicación (es bastante tonto en la forma en que funciona), por lo que los dos se complementan entre sí, no compiten entre sí .
Es decir. No pienses en Barniz o FPC, piensa en Barniz y FPC.