TL; DR - Sur MageStack, nous utilisons Varnish, Redis (cache), Redis (sessions) et Eaccelerator / Zend OPCache (selon la version de PHP)
Vous avez déjà compris l'essentiel.
Le cache, le magasin de session, le cache d'opcode, le cache de page complète et le cache de proxy inverse sont tous complètement différents.
Vous pouvez utiliser différentes technologies pour tous et vous pouvez les utiliser TOUT simultanément (y compris Varnish et un FPC)
Backends cache
- Fichiers (Core) Par défaut
- Memcache (Core)
- APC (Core)
- Redis (<1.9 module avec la permission de Colin Mollenhour)
- MongoDB (module de courtoisie Colin Mollenhour)
- Rubic (module de Daniel Sloof)
Vous ne pouvez utiliser qu'un seul backend de cache.
Contrairement à la croyance populaire, l’utilisation d’un cache basé sur la mémoire n’améliorera pas les performances. Mais il va surmonter certaines failles fatales dans la mise en cache basée sur les fichiers par défaut de Magento.
Au moment de rédiger ce message, Redis est ma recommandation.
Magasins de session
- Fichiers (Core) Par défaut
- Memcache (Core)
- Redis (<1.9 module avec la permission de Colin Mollenhour)
- MongoDB (module de courtoisie Colin Mollenhour)
Vous ne pouvez utiliser qu'un seul magasin de session.
Contrairement à la croyance populaire, l'utilisation d'un magasin de session basé sur la mémoire n'améliorera pas les performances.
Au moment de rédiger ce message, Redis est ma recommandation.
Cache OpCode
- APC
- XCache
- Eaccelerator (PHP <5.4)
- Zend OPCache (PHP> 5.4)
Vous pouvez réellement installer plusieurs caches d'opcode, mais ce n'est pas recommandé, et je ne m'attendrais pas à des gains.
Mes recommandations sont entre parenthèses ci-dessus.
Aucun module n'est requis pour être exploité.
Cache de proxy inverse
- Vernis
- Nginx
- Apache
- … et beaucoup plus
Vous pouvez utiliser plusieurs proxys inverses et, même si cela est complexe et sujet à l’allongement de la mémoire cache, il peut présenter des avantages (par exemple, éviter l’estampage pendant une vidange de la mémoire cache).
Utilisez-en un si nécessaire (c'est-à-dire, non pour accélérer un site lent, mais pour réduire l'utilisation des ressources sur un site rapide).
Pour exploiter un proxy inverse, il faut à la fois activer le côté serveur et un module pour Magento.
Le module a pour but de contrôler la logique de mise en cache (c'est-à-dire de dire au cache ce qu'il devrait ou non de mettre en cache) et de gérer le contenu du cache (c'est-à-dire de déclencher des purges du cache).
Je n'en recommande aucun sauf si vous avez une compréhension totale de ce que vous faites. Des mandataires inverses mal configurés peuvent casser les informations d'en-tête, peuvent causer une perte de session, le partage de session, du contenu obsolète, appliquer des limites supplémentaires au temps de chargement / tampons, consommer des ressources supplémentaires, etc.
Cache de page complet
- EE FPC
- … Beaucoup d'autres (via des modules)
Utilisez-en un si nécessaire (c'est-à-dire, non pour accélérer un site lent, mais pour réduire l'utilisation des ressources sur un site rapide).
Contrairement à la croyance populaire, vous pouvez (et devriez) utiliser un FPC conjointement avec un cache de proxy inverse. Les deux résolvent des problèmes différents et ont des capacités différentes.
Les FPC peuvent tirer parti de plus d’intelligence, car ils ont un accès direct à la session des utilisateurs et au cœur de Magento, alors qu’un proxy inverse n’est pas sensible aux applications (sa façon de fonctionner est assez stupide) - de sorte que les deux se complètent et ne se font pas concurrence. .
C'est à dire. Ne pensez pas Varnish ou FPC, pensez Varnish et FPC.