Le vernis vous convient-il?
Le vernis n'est pas la performance ultime de Magento. C'est génial pour compenser la charge des robots et des acheteurs de fenêtres - mais cela ne devrait pas être votre premier port d'escale pour rendre votre magasin plus rapide.
En fait, l'implémentation de Varnish devrait être la dernière modification des performances de votre magasin. Ne le déposez qu'une fois que vous voyez les temps de chargement des pages que Magento est capable de livrer sans lui (par exemple, <600 ms temps de chargement des pages).
Votre magasin doit encore être rapide
Comme Varnish nécessite toujours au moins une seule page de chargement pour amorcer le cache, cela signifie que vos performances non mises en cache doivent toujours être très bonnes. Une grande majorité d'URL uniques (hits de navigation en couches, requêtes de recherche, etc.) ne seront jamais réellement servies depuis Varnish, sauf si:
a) Vos TTL sont si élevés, qu'une requête de recherche d'il y a 4 jours est toujours valide aujourd'hui
b) La fréquentation du site est si vaste que les URL sont remplies en très peu de temps
Vous devez également considérer que tous les magasins ne se prêtent pas au vernis . Tout site qui encourage les utilisateurs à créer une session personnelle (par exemple, se connecter, ajouter au panier, etc.) au début de leur parcours client signifie que Varnish sera finalement redondant.
Par exemple, les sites commerciaux privés encouragent la connexion des utilisateurs à partir du téléviseur, cependant, ce faisant, cela signifie que Varnish n'a jamais vraiment de contenu non unique pouvant être mis en cache. Vos taux de réussite seront donc considérablement bas et il n'y aura aucun avantage à utiliser Varnish.
Du nouveau contenu ou des taux de réussite plus élevés
Image reproduite avec l'aimable autorisation de magestack.com
L'utilisation efficace de Varnish consiste à trouver un équilibre entre le contenu périmé et le nombre de visiteurs sur votre site.
Si vous avez un site occupé - il y a de fortes chances que vous puissiez vous en sortir avec des TTL inférieurs et avoir toujours un taux de réussite élevé pour le vernis - et continuer à avoir des TTL faibles - donc, un contenu plus frais. Ainsi, vos changements de stock / prix se reflètent rapidement et le cache est continuellement amorcé à partir du volume de fréquentation.
Si vous avez un site à faible trafic, vous devrez faire un compromis. Augmentez vos TTL pour garantir un taux de réussite plus élevé - ou ayez un contenu à jour. Vous ne pouvez pas vraiment avoir les deux. Oui, vous pouvez exécuter un outil d'analyse / araignée en continu - mais les ressources que cela consommerait, et le volume ou les URL qui peuvent être analysés (généralement des dizaines de milliers pour les petits magasins) signifie que ce n'est tout simplement pas efficace. Donc, généralement, les petits magasins bénéficieraient davantage d'une bonne extension FPC et d'une configuration de serveur hautement optimisée.
Mais bien sûr, je peux utiliser Varnish même lorsque les utilisateurs sont connectés, qu'en est-il du cache par utilisateur ou des ESI?
ESI
Les ESI sont un excellent utilitaire pour pouvoir conserver le contenu dans le cache, et toujours avoir des blocs dynamiques sur la page. Mais pour être utilisé efficacement, vous devez réduire au minimum le nombre de rappels. Il y a un petit module de démarrage que vous pouvez utiliser comme base pour ce processus - assurez-vous simplement de resserrer les trous de sécurité, il est très peu sûr par défaut - il n'y a pas de restrictions sur les poignées d'agencement que vous pouvez / ne pouvez pas charger
Chaque fois que le bootstrap Magento est chargé, il en résulte une pénalité de performance d'environ 200 ms - avant même de charger une collection / de rendre un bloc, etc. Donc, si vous avez plus de 3x ESI, il y a de fortes chances que vous vous retrouviez avec des temps de chargement de page plus lents en utilisant Varnish + ESI pour le contenu dynamique, que de simplement contourner Varnish et de passer la demande directement à Magento lui-même.
Donc, pour vraiment utiliser efficacement les ESI, vous devez être en mesure de combiner plusieurs demandes en une seule demande.
Par exemple, une page d'affichage de catégorie répertoriant 20 produits doit afficher des niveaux de stock précis. Vous utilisez donc les ESI pour chaque bloc de la page. Ce serait 20x demandes d'actions ESI. Alors que les demandes de stock sont très légères, en exécuter 20 fois simultanément réduirait les performances. Au lieu de cela, vous pouvez servir l'ensemble du bloc / collection de 20 produits et obtenir simplement cette demande 1x. Mais le chargement et le rendu de la collection est probablement l'élément le plus lent de la page - vous n'avez donc pas beaucoup gagné.
L'utilisation efficace des ESI nécessite une planification et une exécution appropriées, ou vous aurez un site plus lent que de ne pas utiliser du tout de vernis.
Cache par utilisateur
Il y a ensuite l'alternative d'utiliser un cache spécifique à l'utilisateur. C'est une mauvaise idée à moins d'avoir un site à très faible trafic. Votre taux de réussite sera terriblement bas - car les chances qu'un visiteur accède à la même page qu'il est déjà allé sont très faibles. Et pour chaque client, cette page de 6 Ko occupera de plus en plus d'espace dans votre bac de stockage Varnish.
Par exemple, si vous avez alloué 1 Go à Varnish. Avec un site typique où les utilisateurs consultent 8 pages par visite, en moyenne 6 de ces pages seront uniques. Cela représente donc 28 visiteurs par 1 Mo d'espace de stockage. Ensuite, prenez en compte vos images, CSS et JS - celles-ci (heureusement) seront courantes, mais occuperont probablement une bonne quantité de 7 à 800 Mo de votre stockage disponible. Cela vous laisse avec 200 Mo de stockage restants, suffisamment de cache pour 5 600 visiteurs uniques.
Eh bien, je m'en fiche, je veux juste du vernis
D'accord, alors vous devrez faire ce qui suit:
- Installez un terminateur SSL pour vous asseoir avant le vernis (par exemple, stud / pound / nginx)
- Installer Varnish sur le serveur
- Assurez-vous de configurer
X-Forwarded-Forcorrectement
- Installez un module Varnish sur votre boutique
- Configurer vos VCL Varnish pour exclure les extensions tierces
Comme les 3 premiers points dépassent le cadre de cette réponse, je vous laisse le soin de gérer. Le point 4 est un jeu d'enfant et avec le point 5 - continuez à lire.
La chose la plus importante à propos de l'implémentation de Varnish est de s'assurer que vous ne mettez jamais en cache du contenu qui ne devrait jamais être mis en cache.
Par exemple.
- Rappels de passerelle de paiement
- Aperçu du panier
- Aperçu de mon compte client
- Paiement (et appels Ajax respectifs)
etc.
Pour les principales URL Magento, il existe une liste assez standard d'URI que vous pouvez échapper dans Varnish:
admin|checkout|customer|catalog/product_compare|wishlist|paypal
Mais vous devez également prendre en compte toutes les extensions personnalisées / tierces que vous exécutez également et qui ont des itinéraires, des routeurs et des espaces de noms personnalisés. Malheureusement, il n'y a pas de moyen facile de savoir quelles URL de ces extensions peuvent et ne peuvent pas être mises en cache. Vous devez donc évaluer chacun au cas par cas.
En règle générale, chaque fois que nous configurons Varnish, nous commencerons par identifier les routes, routeurs et espaces de noms respectifs qu'ils pourraient occuper et partir de là. Nous le faisons via SSH:
grep -Eiroh "<frontName>.*</frontName>" community | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" community | grep "<from>"
grep -A5 -ir "<routers>" community
grep -Eiroh "<frontName>.*</frontName>" local | sed "s/<frontName>//gI;s#</frontName>##gI" | sort -u
grep -A10 -ir "<rewrite>" local | grep "<from>"
grep -A5 -ir "<routers>" local
Cela ne vous donnera pas une liste définitive d'URL - mais cela vous donnera presque certainement une entrée.
Nous ne pouvons pas souligner à quel point il est important de ne jamais mettre en cache du contenu qui n'est pas censé être mis en cache. Les résultats pourraient être catastrophiques.
En résumé
Comme pour toute autre optimisation des performances du serveur Magento, implémentée et réglée correctement peut vraiment apporter des avantages. Mais simplement laisser tomber le logiciel sans le configurer correctement ne va pas seulement rendre votre magasin pas plus rapide, mais potentiellement plus lent, plus précaire et moins fiable.