Cache pleine page sur CE 1.8 - Un module FPC Magento? Vernis? Tous les deux?

Je suis donc un peu confus lorsque je fais des recherches sur la mise en cache de page complète pour l'édition communautaire 1.8. J'ai déjà implémenté un cache Redis à deux niveaux, CDN, réglé my.cnf de MySQL pour des performances maximales (avec la base de données étant sur un serveur séparé bien sûr), et j'ai 2 serveurs hébergeant notre magasin derrière un équilibreur de charge. Je dis cela pour souligner que je ne saute pas immédiatement pour le FPC avant de faire les réglages de performances initiaux.

Je n'ai jamais utilisé Varnish auparavant sur aucun type de site, sans parler de Magento, et je n'ai jamais non plus configuré de FPC dans Magento. Je comprends que Varnish est un proxy qui agit comme un croisement entre un CDN et un cache de pages, envoyant des données au navigateur avant même que la demande ne parvienne au serveur Web. Et à ma connaissance, un module FPC crée localement un cache que le serveur Web lui-même prépare. Je sais que pour les deux configurations, vous devez faire du "Hole Punching" pour obtenir le contenu dynamique via le navigateur (bien que les techniques soient différentes, entre l'utilisation d'un module ou l'utilisation de Varnish). Veuillez me corriger si je ne comprends rien ici.

Jusqu'à présent, je les considérais comme deux entités distinctes que vous pourriez implémenter pour aider votre site, mais maintenant quelque chose que j'ai lu semble impliquer le contraire. Mon plan initial était d'acheter le module " Warp Advanced Full Page Cache " pour Magento (anciennement le "Tiny Brick Lightspeed FPC", je crois) car il semble être le plus populaire, si une touche du côté le plus cher (mais, franchement, , 350 $ n'est pas beaucoup pour notre entreprise, surtout pour ce qu'elle peut faire). Moi-même et 2 de mes collègues développeurs prévoyions d'apprendre à l'implémenter correctement et pleinement dans notre propre thème personnalisé pour maximiser ce que nous pouvons en tirer. Après cela, à un moment donné, j'ai pensé que j'envisagerais également d'implémenter Varnish - mais, comme je l'ai dit plus tôt, j'avais compris qu'ils étaient séparés.

Maintenant, cependant, je commence à rencontrer des extensions comme ce PageCache Powered by Varnish qui est gratuit, ou ce Vortex Cache Powered by Varnish Cache qui coûte près de 800 $ USD, qui sont des modules Magento Full Page Cache qui fonctionnent directement avec Varnish.

Ma question pour vous, échange de pile, est comment dois-je voir un FPC et un vernis? En tant qu'entités distinctes? Si oui, sont-ils mutuellement exclusifs? Sont-ils les deux faces d'une même médaille que je dois mettre en œuvre ensemble? Ou sont-ils similaires mais ni exclusifs ni inclusifs les uns des autres?

Puis-je utiliser le Warp Advanced FPC que j'ai mentionné ci-dessus avec Varnish? Dois- je l'utiliser avec du vernis? Ou serait-il préférable d'utiliser un FPC différent si je prévois d'utiliser Varnish? OU encore plus, y a-t-il un FPC si bon que je n'ai pas besoin de vernis? Ou vice-versa, dois-je simplement utiliser Varnish et abandonner l'idée FPC?

Désolé pour le mur de texte, mais j'ai consulté de nombreux articles, blogs et messages sur le forum, et je n'ai pas été en mesure de discerner une réponse définitive à ces questions. J'apprécie vraiment votre aide et votre contribution à ce sujet =)

Oh et enfin, une question rapide sur Varnish et les serveurs Web. Actuellement, j'utilise la configuration normale de la pile Apache LAMP, mais depuis un certain temps, je vois des gens s'extasier sur l'utilisation de Nginx avec Magento. J'ai fait moi-même des tests, des tests de stress et de charge, et il semble que cela puisse certainement fonctionner un peu mieux dans les bonnes conditions. En tant que tel, j'envisageais de changer à un moment donné dans un proche avenir. Cela affecterait-il de toute façon mon désir et ma décision d'utiliser un FPC et / ou un vernis?

Je vous remercie!!!

EDIT: Oh! Et une autre question rapide - Étant donné que j'ai deux serveurs hébergeant mon site derrière un équilibreur de charge (qui est également une configuration qui peut être augmentée horizontalement si le besoin s'en fait sentir), j'utilise pleinement Redis et Memcached hébergés sur un serveur distinct du Web et DB pour mes sessions et chaque niveau du cache à deux niveaux de Magento (enfin, Zend). Je suppose que le FPC stockerait ses données dans l'un de ces systèmes? Aurais-je besoin d'une extension spécifique pour la stocker ou est-ce qu'ils le font tous? Et même si je suppose que non, cela affecterait-il le vernis de toute façon? Merci encore!!

Il y a deux choses difficiles en informatique:

1. Nommer les choses
2. Invalidation du cache.

Le poinçonnage appartient à la catégorie # 2 :)

Général

La meilleure approche consiste à commencer aux points inférieurs de la pile et à optimiser jusqu'au frontend de Magento.

Base de données et système de fichiers

Devrait toujours être les premiers domaines sur lesquels se concentrer. Car. E / S.

MyTop est un script perl pratique basé sur Linux qui imitera la commande 'top' de Linux et vous donnera un aperçu de l'état de vos instances MySQL.

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

Htop est un sommet plus robuste , la fonction strace peut aider à déterminer les entrées / sorties d'un processus pour trouver des goulots d'étranglement potentiels.

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

Iotop est un autre outil à considérer pour surveiller les E / S.

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

D'autres scripts utilitaires pratiques comme mysqltuner.pl et mysql tunning primer peuvent offrir un aperçu de vos variables d'exécution MySQL et offrir des conseils pour vous aider. Gardez à l'esprit que ceux-ci sont censés être des guides car la meilleure approche est toujours une évaluation des exigences et un réglage basé sur les données connues recueillies. Le faire aveuglément peut parfois causer plus de dégâts que de bien. Et les exécuter prématurément sans au moins 24 heures de variables d'exécution mysql peut offrir de mauvais conseils.

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

Gardez à l'esprit que Percona , MariaDB et MySQL standard devraient fonctionner avec tout ce qui précède. Favoriser Percona en tant que fork MySQL, puisque Magento est si lourd sur InnoDB et XtraDB offre de nombreux outils et améliorations au moteur db.

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

Apache ou Nginx

Toujours en utilisant Apache car il a bien servi de nombreux autres, moi y compris. J'ai également utilisé et configuré Nginx. Bien qu'il offre certains avantages, il existe une courbe d'apprentissage. Bien que les deux soient les deux options populaires, il offre certains avantages par rapport à Apache, l'un serait une empreinte mémoire plus petite. Cependant, un Apache allégé exécutant PHP-FPM aura une empreinte mémoire similaire.

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

Exemple concret:

Étant donné que cet article concernait les performances, je dois souligner que l'un des moyens les plus simples d'aider Apache à se démarquer est de ne pas utiliser les fichiers .htaccess. Mettez ce que vous y mettriez dans vos strophes de répertoire, définissez AllowOverride sur "None" et vous finissez par ne pas demander à apache de parcourir le chemin du document entier pour déterminer s'il doit ou non prêter attention à .htaccess. Il s'agit d'un indice de réglage simple et de base que beaucoup de gens semblent manquer.

Pour faciliter cette vérification:

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

L'utilisation d'un CDN pour aider à soulager l'un ou l'autre aidera évidemment, mais aura un avantage supplémentaire sur l'optimisation frontale car la plupart des navigateurs des utilisateurs finaux pourront se connecter aux deux serveurs avec le même nombre de limites de connexion. Cela évite également à Apache de ne pas avoir à passer par les contrôles et tout simplement pour servir une simple image statique. Lighthttpd est une option si vous souhaitez exécuter un serveur Web statique uniquement pour le contenu en plus d'un CDN.

PHP

PHP-FPM et APC. Utilisez-les, supprimez tous les modules PHP inutiles ou non nécessaires non nécessaires pour Magento.

Base de code Magento

AOE_TemplateHints est idéal pour déterminer si vos blocs sont correctement mis en cache:

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

AOE_Profiler est bon pour le profilage, assurez-vous et activez son profilage de couche DB (dans un environnement local / dev évidemment). En conjonction avec l' outil mytop mentionné précédemment, il est plus facile de trouver le mauvais comportement de SQL.

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

Modules tiers et code personnalisé

Quelques bonnes pratiques d'optimisation de Magento elles-mêmes sont une bonne lecture, et à garder à l'esprit lors de l'examen des modules tiers avant de les utiliser. (il y a beaucoup de mauvais comportements IMO).

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

Un outil Magniffer de Magento ECG aidera à identifier facilement le code de mauvais comportement basé sur le PDF fourni ci-dessus. Il est cependant basé sur symfony / php-parser mais installable via composer.

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

Vernis

En tant que défenseur de Varnish, l'auteur était un développeur du noyau FreeBSD, il offre des temps de chargement fous d'une seconde. Cependant, si vous avez même certaines des moindres différences dans vos modèles qui ne sont pas prêtes à l'emploi, vous passerez du temps à configurer vernis / magento pour holepunch le contenu dont vous avez besoin. La plupart que j'ai vus vont simplement AJAX'ify les éléments nécessaires mis en cache de Varnish.

Il existe un certain nombre de modules Magento pour faciliter cette perforation et cette mise en cache:

• AOE_Static: https://github.com/AOEmedia/Aoe_Static
• Nexcess Turpentine: https://github.com/nexcess/magento-turpentine

En fin de compte, cela devrait être à la dernière fin de votre parcours d'optimisation et PEUT nécessiter une personnalisation pour bien faire les choses.

Magento CE FPC

Jusqu'à présent, le meilleur FPC CE que j'ai trouvé est: Lesti :: FPC

il s'agit d'un FPC open source et gratuit très bien conçu (basé sur des observateurs) pour la communauté.

• http://gordonlesti.com/lestifpc/
• https://github.com/GordonLesti/Lesti_Fpc (github en cas de futur lien mort)

À la fin de la journée, utilisez vos propres tests et votre jugement.

Quelques lectures supplémentaires:

• 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

Je connais un peu tard ce fil, mais si vous cherchez toujours une solution, vous voudrez peut-être envisager la mise en cache évoluée . C'est le même prix que Warp, mais il:

• Est très rapide et facile à installer et à configurer - toutes les perforations et configurations de trous sont effectuées depuis l'administration
• S'intègre directement avec Varnish et vous permet de vider et de réchauffer votre cache Varnish depuis Magento
• Fonctionne avec le form_key frontal introduit dans 1.8 CE dans Varnish et son propre cache.
• Est développé très activement avec un support réactif. Nouvelles versions régulières dans le but de publier des corrections de bogues dans les quelques jours suivant la notification
• Dispose d'une documentation complète qui est mise à jour avec chaque version

La configuration avec Varnish est simple, il vous suffit d'activer un paramètre administrateur et d'utiliser le .vcl trouvé ici . Vous n'êtes pas non plus limité à Varnish ne servant que le cache quand aucun cookie n'est présent normalement - vous obtenez un taux d'accès au cache très élevé.

Nous avons écrit un FPC compatible avec la nouvelle clé de formulaire Magento 1.8. Cache pleine page de Brim: http://ecommerce.brimllc.com/full-page-cache-magento.html

BOOMER fait un bon point sur le fait de commencer bas sur la pile et de progresser. Un FPC ou un vernis devrait être le dernier que vous fassiez. Nous effectuons des audits de performances et constatons généralement des problèmes avec les configurations MySQL et APC qui sont vraiment hors service. Comme les tailles de mémoire tampon Innodb définies par défaut et la base de données a grandi bien au-delà.

Nous vous déconseillons d'utiliser un FPC avec du vernis, sauf s'il est spécifiquement conçu pour fonctionner ensemble. En règle générale, nous ne recommandons pas Varnish, sauf si vous avez une poignée de serveurs costauds qui ont tous été réglés avec votre base de code et qui ont toujours du mal à suivre le trafic. La mise à jour du contenu dynamique peut être délicate avec Varnish en particulier lorsque vous essayez de limiter vos demandes au backend de Magento et à son tour de réduire la charge. Si vous avez une ou deux têtes Web, les gains ne valent peut-être pas le temps et les complications.

Dans la plupart des situations, un bon FPC vous obtiendra les performances dont vous avez besoin, bien sûr après que votre serveur et votre base de code ont été réglés. Avec notre FPC, vous pouvez obtenir des temps de génération inférieurs à 15 ms sur le cache de niveau 1 et inférieurs à 100 ms sur le cache standard. Notre cache de niveau 1 est utilisé dans les cas où l'utilisateur n'est pas connecté et n'a rien dans son panier car il ne fait pas de perforation. Lorsque l'une de ces conditions est fausse, le cache standard est utilisé avec le support de perforation de trous complets.

Notre FPC a un poinçonnage facile intégré et fonctionne immédiatement avec tous les blocs Magento standard ainsi que tous les blocs personnalisés que vous pourriez avoir. Tout est configurable via le panneau d'administration.

Je recommanderais de rester avec Redis, sauf si vous rencontrez des problèmes de mise à l'échelle avec lui. Il prend en charge les balises et est beaucoup plus rapide que memcached avec un fichier ou une base de données en tant que backend lent. Si vous voulez des balises cohérentes et un nettoyage, vous devez utiliser memcached avec la base de données lorsque vous avez plusieurs têtes Web. Avec la prise en charge des balises de Redis intégrée, vous n'avez pas à vous en soucier. Vous pouvez également utiliser Redis pour vos sessions.

Je peux parler pour tous les FPC, mais avec les nôtres, vous pouvez configurer via l'administrateur où les stocker. Vous pouvez choisir d'utiliser le backend de cache Magento par défaut ou spécifier des paramètres personnalisés pour utiliser File, Database, APC, Redis, Memcache et un backend de fichier optimisé.

Il n'y a pas de bonne réponse. Un magasin devrait avoir des charges de pages dynamiques inférieures à 3 secondes et idéalement des charges de pages dynamiques de 1 à 2 secondes, une sous-seconde n'est pas nécessaire et est principalement une statistique axée sur le marketing. Apache est facile à apprendre et difficile à faire performer, Nginx est difficile à apprendre et facile à faire performer, de nombreux sites passent à Nginx mais avoir une architecture de haute qualité basée sur Nginx et Magento n'est pas simple.

Les clusters Magento multi-serveurs sont déjà complexes à implémenter, et encore plus difficiles à maintenir s'ils ne sont pas sur la bonne architecture, nous travaillons normalement avec des clusters plus grands, ce qui rend tout plus fluide, y compris le classement. Nous le faisons avec une configuration d'installation standard avec des changements mineurs pour la stabilité à moyen et long terme ciblant les chargements de pages dynamiques 1-2s, cela rend tout beaucoup plus simple pour la maintenance.

Le vernis peut être un FPC, CDN entre autres, mais dans votre cas, il est préférable de le considérer comme un FPC. Un FPC permet à plus de visiteurs sur le serveur et fournit une livraison statique plus rapide dont Varnish est un de ces outils, mais il présente divers problèmes, notamment le contenu dynamique, le contrôle des stocks et la tarification. La réponse se résume à la façon dont votre entreprise est structurée, à la façon dont vos données sont chargées, à quelle fréquence, à votre type d'hébergement et plus encore, votre entreprise est simplement affectée par la fourniture de contenu statique aux visiteurs. Techniquement, vous pouvez atténuer une grande partie de cela avec la configuration FPC, mais cela complique l'environnement commercial, du point de vue du propriétaire d'entreprise, il peut ne pas produire un retour sur investissement équilibré.

Le FPC est la dernière partie si vous avez un chargement dynamique inférieur à 3 ou supérieur, votre architecture peut gérer l'ampleur des demandes des visiteurs car cela affecte le classement, absorber les pics de marketing et de vacances et avoir le budget pour ajouter de la complexité à l'architecture du serveur - l'hébergement devrait être de 0,5 -1% du chiffre d'affaires pour les petites entreprises, la plupart s'exécutant de manière substantielle sous ce qui provoque de nombreux problèmes commerciaux indirects.

La raison pour laquelle vous n'avez pas trouvé de réponse définitive est due au fait que ces questions mettent des mois à répondre car elles sont qualitatives (basées sur les affaires) qui nécessitent des informations qu'une entreprise ne voudrait pas publier publiquement, les vitesses de chargement des pages sont quantitatives (basées techniques ) qui peut être affiché publiquement, c'est la façon dont vous combinez les deux qui fait la solution.

Vous pouvez utiliser ce cache de page Magento qui répondra à vos besoins et est similaire au vernis. Il est utilisé par la plupart des plus grands magasins Magento. Certaines fonctionnalités:

1. Comme Varnish, il n'utilise pas de connexion à la base de données pour 90% des requêtes. En conséquence, il est extrêmement rapide
2. Il a la capacité de vider automatiquement les pages lorsque des choses comme l'inventaire des produits changent et il est très bon dans ce domaine
3. Il s'agit d'un cache multicouche, il prend donc également en charge la perforation lorsque les utilisateurs se connectent (ces demandes nécessitent l'utilisation de la base de données)

En tant que cache à plusieurs niveaux, il est évolutif même pour les magasins à trafic le plus élevé et a été utilisé sur de nombreux sites à très fort trafic qui reçoivent un trafic de pointe, tels que les magasins présentés sur SharkTank (émission de télévision)