Les modifications requises pour l'utilisation de vernis sur Magento CE

Question

J'ai du mal à trouver de bons exemples de travail de quelles modifications sont nécessaires pour permettre Varnish de mettre en cache un site Magento.

Idéalement, je voudrais une liste de tâches, telles que les choses à l'activation / désactivation et où les chercher. Il serait également bon d'avoir la config Varnish que ces changements sont conçus pour fonctionner avec.

Le guide de performance Magento parle beaucoup Varnish, donc je sais qu'il a été fait avant, mais il n'explique pas vraiment comment le faire fonctionner.

Answer 1

Ils ont un module officiel droit . Il comprend tout ce dont vous avez besoin (config de vernis, module, ...)

Answer 2

est Varnish pour vous?

Le vernis est pas l'alpha et la fin de toutes les performances Magento. Son grand pour compenser la charge contre les robots collecteurs et lèche-vitrines -. Mais il ne devrait pas être votre premier port d'escale pour faire réellement plus vite votre magasin

En fait, la mise en œuvre Varnish doit être dernier modification de la performance à votre magasin. Seulement déposer dans une fois que vous voyez le temps de chargement de la page Magento est capable de délivrer sans elle (par ex. <600ms temps de chargement de la page).

Votre magasin doit encore être rapide

Varnish nécessite encore au moins une seule charge de page pour amorcer le cache, cela signifie que votre performance non mise en cache doit encore être très bon. Une grande majorité des URL uniques (hits de navigation en couches, les requêtes de recherche, etc.) ne sera jamais vraiment finir par être servi de Varnish à moins que ce soit:

a) Vos TTLs sont si élevés, qu'une requête de recherche d'il y a 4 jours est toujours valable aujourd'hui
b) Le bruit de pas sur le site est si vaste que les URL sont peuplées dans un très court laps de temps

Vous devez également considérer que pas tous les magasins se prête à vernir . Tout site qui encourage les utilisateurs à créer une session personnelle (par exemple. Connecter, ajouter à panier, etc.) au début de leur parcours client signifie que Varnish sera finalement redondant.

Par exemple, cependant, les sites commerciaux privés encouragent la connexion utilisateur du jeu sur, en faisant cela, cela signifie que Varnish n'a jamais vraiment contenu non unique qui est cache-mesure. Donc, votre taux de succès seront considérablement bas et il n'y aura aucun avantage de l'utilisation de vernis.

Du nouveau contenu ou des taux de réussite plus élevés

^{Avec l'aimable autorisation de magestack.com}

L'utilisation Varnish est effectivement tout sur un équilibre entre le contenu périmé et la quantité de visiteurs sur votre site.

Si vous avez un site occupé - les chances sont que vous pouvez vous en sortir avec TTLs inférieurs et ont encore un haut taux de succès Varnish - et aussi continuer à avoir de faibles TTLs - ainsi, le contenu plus frais. Donc, vos modifications stock / prix se reflètent rapidement et le cache est continuellement amorcées à partir du volume de bruit de pas.

Si vous avez un site à faible trafic - alors vous allez devoir faire un compromis. Soit augmenter vos TTLs pour assurer un taux de réussite plus élevé - ou ont contenu à jour. Vous ne pouvez pas tout à fait les deux. Oui, vous pouvez exécuter un outil rampent / araignée en permanence - mais les ressources que ce consommeriez et volume ou URL qui peuvent être explorées (généralement des dizaines de milliers pour petits magasins) signifie que sa simple Inefficace. Donc, en général, les petits magasins bénéficieraient plus d'un bon et ayant l'extension FPC une configuration de serveur hautement optimisé.

Mais bien sûr, je peux utiliser Varnish même lorsque les utilisateurs sont connectés, qu'en est-cache par utilisateur ou EES?

EES

ESI sont un excellent utilitaire pour être en mesure de garder le contenu dans le cache, et être encore capable d'avoir des blocs dynamiques sur la page. Mais, pour être efficace, vous devez réduire la quantité de callbacks au strict minimum. Il y a une petite tête-début Module vous pouvez utiliser comme base pour ce processus - juste être sûr vous resserrez les trous de sécurité en elle, son très précaire par défaut - il n'y a pas de restrictions sur ce que la mise en page poignées vous pouvez / ne peut pas charger

Chaque fois que le bootstrap Magento est chargé, il est à une pénalité de performance d'environ 200 ms - avant même charge une collection / Renders un bloc, etc. Donc, si vous avez plus de 3 fois FEIS les chances sont que vous avez a fini avec plus lent temps de chargement de page à l'aide Varnish + pour le contenu dynamique EES, qu'un simple contournement Varnish et passer ledirectement à Magento lui-même.

Donc, pour vraiment utiliser efficacement, ESI vous devez être en mesure de combiner plusieurs demandes dans une seule requête.

Par exemple, une page de vue Liste des catégories 20 produits doit montrer le niveau des stocks précis. Donc, vous utilisez ESI est pour chaque bloc sur la page. Ce serait 20x demandes d'achat d'actions ESI. Alors que les demandes d'achat d'actions sont très légers, en cours d'exécution 20x d'entre eux en même temps écraser la performance. Ainsi, au lieu, vous pouvez servir tout le bloc / collection de 20 produits et simplement obtenir cette demande de 1x. Mais le chargement et le rendu de la collection est sans doute le plus lent élément sur la page de toute façon -. De sorte que vous ne l'avez pas gagné beaucoup

Utilisation de ESI est effectivement besoin planing et une exécution, ou vous aurez un site plus lent que ne pas utiliser Varnish du tout.

Cache par utilisateur

Ensuite, il y a la possibilité d'utiliser un cache spécifique à l'utilisateur. Ceci est une mauvaise idée, sauf si vous avez un site très faible trafic. Votre taux de succès sera terriblement faible - comme les chances sur un visiteur frappant la même page qu'ils ont déjà visité sont très faibles. Et pour chaque client, cette page 6Ko sera de plus en plus occupe l'espace dans votre bac de stockage Varnish.

Par exemple, si vous avez alloué 1 Go à vernir. Avec un site typique où les utilisateurs visualisent 8 pages par visite, en moyenne 6 de ces pages sera unique. Donc, c'est 28 visiteurs par 1 Mo de stockage. Puis facteur dans vos images, CSS et JS - ces (heureusement) sera commune, mais encore occuper probablement une bonne 7-800MB de votre stockage disponible. Ce soin vous avec 200 Mo de stockage restant, cache suffisant pour 5.600 visiteurs uniques.

Eh bien, je ne me soucie pas, je veux juste Varnish

D'accord, alors vous devrez effectuer les opérations suivantes:

1. Installer une terminaison SSL pour s'asseoir avant Varnish (par exemple. Stud / livre / nginx)
2. Installer Varnish sur le serveur
3. Assurez-vous de configurer correctement X-Forwarded-For
4. Installer un Module Varnish sur votre magasin
5. Configurer votre Varnish VCLs pour exclure les extensions 3ème partie

Comme les 3 premiers points sont au-delà de la portée de cette réponse, je vais laisser vous à manipuler. Le point 4 est un jeu d'enfant et au point 5 -. continuer à lire

La chose la plus importante sur la mise en œuvre est d'assurer Varnish que vous jamais contenu du cache qui ne devrait jamais être mis en cache.

Par exemple.

• callbacks passerelle de paiement
• Panier aperçu
• aperçu client mon compte
• Commander (et les appels Ajax respectifs)

etc.

Pour le noyau URL Magento, il y a une liste assez standard de URIs que vous pouvez échapper à Varnish:

admin|checkout|customer|catalog/product_compare|wishlist|paypal

Mais vous avez aussi besoin d'envisager des extensions personnalisées / 3e partie que vous exécutez également qui ont des itinéraires personnalisés, les routeurs et les espaces de noms. Malheureusement, il n'y a pas un moyen facile de savoir ce que les URL de ces extensions peuvent et ne peuvent pas être mises en cache. Vous avez donc besoin d'une évaluation chacun sur une base au cas par cas.

En règle générale, chaque fois que nous configurons Varnish, nous allons commencer par identifier les itinéraires respectifs, les routeurs et les espaces de noms qu'ils pourraient occuper et aller 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 des URL -. Mais il vous donnera certainement un démarreur

Nous ne pouvons pas souligner combien il est important de ne jamais le contenu du cache qui n'est pas censé être mis en cache. Les résultats pourraient être catastrophiques.

En résumé

Comme toute autre l'optimisation des performances du serveur Magento, mis en œuvre et correctement réglé peut vraiment donner des avantages. Mais simplement tomber dans le logiciel sans correctement la configuration, il est non seulement va rendre votre magasin pas plus rapide, mais potentiellement plus lente, plus précaire et moins fiables.