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!

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 .}

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.

1. Les informations sur les actions / prix sont obsolètes jusqu'à l'invalidation ou l'expiration du TTL

2. 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

1. Vous n'avez pas assez de fréquentation naturelle pour garder les caches amorcées (voir 'Où FPC est utile')
2. 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

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

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

1. mage-perftest
2. HTTrack
3. Nutch
4. Sphider
5. 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

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.