Préchauffage du cache de page complète de Magento Enterprise

Les avantages en termes de performances du cache pleine page dans Magento Enterprise sont assez bien connus. Ce qui n'est peut-être pas aussi bien connu, c'est que pour en tirer pleinement parti, il doit être entièrement rempli et chaud, en particulier sur les grands ensembles de produits où vous n'avez pas seulement quelques pages, ce qui permet d'utiliser le trafic organique vers amorcez-le assez rapidement.

Magento comprend un cronjob intégré pour explorer le site et réchauffer le FPC tôt le matin.

J'ai vu et entendu des problèmes causés par des travaux tôt le matin qui prennent trop de temps à exécuter, empêchant d'autres travaux de s'exécuter, et j'aimerais savoir ce que les autres utilisent ou suggéreraient pour faire cela. Quelques idées que j'ai:

Composez un script shell pour explorer chaque page du fichier sitemap généré.
Utilisez une entrée crontab distincte et un court script PHP pour amorcer Magento et exécuter directement le processus du robot.

Toute réflexion et / ou expérience à ce sujet est la bienvenue!

— davidalger
source

En fait, vous pouvez appeler le robot d'entreprise à partir d'un fichier séparé et utiliser la crontab de vos serveurs pour le déclencher afin qu'il ne soit pas gênant.

— Toon Van Dooren

Vous pouvez utiliser le siège en combinaison avec le sitemap.xmlfichier, comme le fait MageSpeedTest .

#categories
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
#products
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1.0 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' >> urls.txt

Ensuite, exécutez

siege -i -c 1 -t 7200s -f urls.txt

^{Contenu provenant d' ici .}

— Ashley Schroder
source

Vous pouvez également ajouter un délai entre les demandes en utilisant–delay

— Ben Lessani - Sonassi

Remarque: Ces commandes sed ne fonctionnent pas sur Darwin, mais le font sur CentOS.

— davidalger

Cela ne garantit pas que chaque URL sera "réchauffée". le siège sélectionnera aléatoirement les URL à frapper du fichier, mais ne visitera pas nécessairement toutes les URL.

— Joe Constant

Nous ne le faisons tout simplement pas - du tout. Déjà. Nous le répéterons encore et encore, mais

Mise en cache! = Performance

Votre site doit être rapide sans l'ajout de FPC (ou de vernis pour cela). Il y aura toujours un moment où le contenu ne sera pas amorcé (votre scénario ci-dessus).

Sur un magasin déchargé, les temps de chargement des pages avec FPC ne devraient pas être beaucoup plus impressionnants que les non-FPC; Magento est tout à fait capable de < 400mstemps de chargement de page sur les caches standard (sur les pages catégorie / produit / recherche). Le FPC ramènera cela à < 80ms- mais vient avec des mises en garde.

Les informations sur les actions / prix sont obsolètes jusqu'à l'invalidation ou l'expiration du TTL
Les nouveaux éléments / la recherche plus pertinente sont obsolètes jusqu'à l'invalidation ou l'expiration du TTL

etc.

Pourquoi se fier au FPC (ou au vernis) est une mauvaise idée

Si vous cherchez continuellement à amorcer manuellement les caches, il y a probablement plusieurs raisons

Vous n'avez pas assez de fréquentation naturelle pour garder les caches amorcées (voir 'Où FPC est utile')
Votre site est trop lent sans eux

Vous ne pouvez pas tout mettre en cache

Si vous prenez un magasin avec seulement 5 catégories, imbriqué 2 niveaux de profondeur, 5 attributs filtrables, 5 options d'attributs chacun et 1000 produits; c'est beaucoup de combinaisons possibles.

25 options au choix, en choisissant une jusqu'à 5 fois de suite - Je ne suis pas un statisticien , mais je sais que c'est ... (en supposant que le nombre d'options d'attributs ne diminue pas complètement)

25 possible URLs on the first selection
20 possible URLs on the second selection
15 possible URLs on the third selection
10 possible URLs on the fourth selection
5  possible URLs on the fifth selection

5^5 = 3,125 possible combinations (for top level categories)
5^4 = 625 possible combinations (for 2nd level categories)

Ok, ce qui précède n'est pas un scénario probable, comme j'imagine, en 3 clics - le nombre de produits disponibles aurait suffisamment diminué pour que le client trouve son produit. Donc, même si c'était le cas ...

25 possible URLs on the first selection
10 possible URLs on the second selection
3 possible URLs on the third selection

5^3 = 125 possible URL combinations

Puis multiplie cela par 5 catégories, soit 625 URL. À ce stade, nous parlons d'un petit catalogue et ignorant complètement toutes les URL des produits.

Nous ne tenons pas compte non plus du fait que si vous aviez des catégories imbriquées avec is_anchor, cela va augmenter de façon exponentielle.

Donc, pour explorer ce volume de pages - vous devez soit espérer que vos temps de chargement des pages sont agréables et bas pour commencer, de sorte que c'est un processus rapide et léger (ce qui va à l'encontre du but de l'analyse) - ou que vous avez suffisamment de temps pour qu'il se termine avant l'expiration du TTL.

Si vos pages avaient un temps de chargement de 0,4 s et que vous aviez un processeur à 8 cœurs - alors ...

625 * 0.4 = 250 / 8 = 31 seconds

0,5 minutes, pas mal - mais imaginons que vous avez eu des temps de chargement de 2 secondes

625 * 2 = 1250 / 8 = 156 seconds

Mais si vous avez pris le maximum de scénario possible

3,750 * 2 = 7,500 / 8 = 937 seconds ~ 15 minutes

Voilà donc votre serveur de production, sous 100% de charge CPU pendant 15 minutes. Vous réduisez la vitesse d'exploration proportionnellement au TTL souhaité.

Donc, si vous voulez que le contenu ait un TTL de 3600s, l'exploration pourrait être 4 fois plus lente - c'est-à-dire. seulement 25% de CPU dédiés à l'exploration. C'est beaucoup de ressources juste pour garder le contenu de la catégorie en tête - nous n'avons même pas pris en compte les produits, les termes de recherche ou les vues de magasin supplémentaires à ce stade

En fait, le simple fait de regarder la taille des combinaisons dans le catalog_url_rewritestableau (qui ne tient même pas compte des paramètres de la navigation en couches) vous donnera une idée du nombre d'URL que vous pourriez avoir besoin d'explorer.

Chaque magasin sera certainement différent, mais ce que j'essaie de faire, c'est que l'exploration du site pour amorcer FPC n'est pas pratique. Assurez-vous simplement que votre magasin est rapide pour commencer .

Où FPC est utile

Là où les avantages du FPC entrent en jeu, c'est dans un magasin lourdement chargé - où vous avez un niveau de trafic vraiment élevé et où les caches sont naturellement et continuellement amorcées par une simple chute de pied.

FPC entre alors en jeu en réduisant les frais généraux de l'infrastructure sur le contenu couramment demandé - en réduisant ces appels répétés au backend Magento.

Nous avons donc constaté que FPC est excellent à déployer lorsque vous avez des niveaux de trafic très élevés - non pas pour réduire le temps de chargement des pages - mais pour réduire l'utilisation des ressources.

Peu importe, je veux toujours ramper

Eh bien, vous avez deux options

Explorer à partir d'un modèle (par exemple, plan du site)
Extrayez les liens page par page et explorez chacun

Et il existe de nombreux utilitaires pour les deux, ce sont certains que je connais

mage-perftest
HTTrack
Nutch
Sphider
Crawler4j

Utilisation de Mage-Perftest

Vous pouvez explorer votre boutique avec Mage-Perftest assez facilement, téléchargez-le d'abord

wget http://sys.sonassi.com/mage-perftest          (64bit) OR
wget http://sys.sonassi.com/mage-perftest-i386     (32bit)
chmod +x http://sys.sonassi.com/mage-perftest*

Définissez ensuite le processus d'analyse à l'aide du plan du site Magento (vous pouvez le personnaliser en créant un plan du site de toutes les URL, à condition que les URL soient enveloppées dans des <loc></loc>balises). La commande suivante lira toutes les URL du fichier sitemap, puis analysera (PHP uniquement) les URL en 1440 minutes (1 jour). Si le serveur dépasse 20% de CPU ou une moyenne de charge de 2 - l'analyse s'arrêtera temporairement.

./mage-perftest -u www.example.com -s www.example.com/sitemap.xml -r auto -b -d 1440 -z -a 20 -l 2

Si vous avez 1000 URL, explorées sur 1 jour, cela fera environ. 1 demande toutes les 86 seconde (s) ~ objectif de 0,011 RPS

— Ben Lessani - Sonassi
source

Vous ouvrez la ligne est très vrai… la mise en cache des pages n'est pas le moyen d'atteindre des performances. Je sais ça. Vous ne savez pas combien de fois j'ai dit la même chose à mes clients. Je vais être honnête, je n'ai jamais configuré de site où nous avons un robot amorçant le FPC auparavant, et je ne l'ai vu utilisé qu'une fois lorsqu'un client l'a activé dans l'admin… ralentissant les choses depuis leurs balises de cache basées sur des fichiers. La principale raison pour laquelle je pose cette question est que j'explore des idées à ce sujet sur la base de certaines recherches dans le livre blanc de Nexcess. Pour les sites à trafic incroyablement élevé, l'amorçage du cache après l'avoir vidé tôt le matin peut être critique

— davidalger

Je respecte Nexcess - mais leur livre blanc se concentre très fortement sur la mise en cache pour obtenir des performances - plutôt que de s'assurer que l'environnement est déjà performant et que le code est propre, rapide et efficace. Nous fournissons du vernis à nos clients - mais ne préconisons pas son utilisation tant que cela n'est pas nécessaire. Alors seulement comme moyen de réduire les coûts d'infrastructure - ie. lorsque ~ 94% du trafic non converti / extrait consomme des cycles CPU. La mise en cache permet d'obtenir de belles statistiques de référence artificielles - mais ne signifie rien en réalité si les TTL sont trop longs (contenu périmé) - ou s'il n'y a pas assez de trafic pour le maintenir amorcé.

— Ben Lessani - Sonassi

Pour les sites à trafic incroyablement élevé - nous en avons quelques-uns, et essayer de garder un cache chaud grâce à l'exploration artificielle est inutile - le trafic naturel le fait très bien. Si quoi que ce soit, l'exploration supprime simplement les ressources qui seraient autrement utilisées par les clients.

— Ben Lessani - Sonassi

Je prie de différer sur leur livre blanc en se concentrant sur l'utilisation de la mise en cache pour les performances. Ils montraient le débit qu'un cluster 2 + 1 pouvait atteindre. Ils n'y ont même pas abordé les temps de chargement des pages, seulement le débit des transactions. Le matériel dont ils disposent est à peu près aussi optimisé que possible… et oui, je me rends compte des effets des TTL sur le contenu mis en cache. Juste pour réitérer, je ne cherche pas à obtenir des performances ici, nous l'avons déjà. Ce que cela explorerait, ce serait des moyens de contourner les retards / baisses de débit dus à la purge du cache tôt le matin, c'est-à-dire avant que le trafic normal ne reprenne.

— davidalger

Je suis confus alors. Si votre magasin est déjà rapide - mais tombe lorsque vous videz le cache. Soit a) Ne videz pas le cache le matin, faites-le la veille et laissez les robots d'exploration de recherche (google / bing etc.) faire l'amorçage pour vous ou b) obtenez la bonne infrastructure. Si votre magasin dépend du FPC / Vernis pour éviter les retards / ralentissements - alors il semble que vous

— couriez

Je garderai ma diatribe complète pour un article de blog ces jours-ci, mais en attendant, j'ai un pic à mon petit cache-cache wfpc.

Test des performances

Vous pouvez tester les performances de votre site Magento

./wfpc -t http://mymagentosite.com/sitemap.xml

Finished testing your Magento site performance
Total download time (in seconds)   : 5.0269110202789
Total download time (formatted)    : 0:0:5.026
Average page time (in milliseconds): 502.69110202789

Réchauffement FPC

Et vous pouvez réchauffer le FPC, qui frappera chaque URL dans sitemap.xml.

./wfpc -w http://mymagentosite.com/sitemap.xml

Vous pouvez également mettre un délai entre les requêtes si vous le souhaitez, voici un délai de 1 seconde entre les requêtes.

./wfpc -w -d=1 http://mymagentosite.com/sitemap.xml

Le mode de test ne frappe que 10 URL au hasard, donc une fois que vous avez réchauffé votre FPC, vous pouvez exécuter le mode de test pour découvrir à quel point le FPC fait une différence!

Pensées

Personnellement, je pense qu'un réchauffeur a du sens ... Sur un petit site d'environ 40 pages, le temps de téléchargement est réduit de moitié environ par le FPC. Sur un grand site avec près de 40000 produits utilisant Lesti_FPC avec APCu comme backend, j'utilise un peu plus de 200 Mo pour le cache, ce qui n'est franchement rien sur le serveur de production de 8 Go.

— quickshiftin
source