Pendant des années, nous avons ouvertement partagé notre connaissance et notre R&D autour de l’optimisation de Magento avec la communauté. Cependant, certains de nos contenus (articles, recherches, outils, manuels et conférences) ont fait l’objet de récupération par des tiers s’appropriant notre expertise. Ainsi, pendant longtemps nous avons limité nos publications et diffusions publiques de notre savoir Magento.

Pour 2016,  nous prévoyons de ré-éditer le Benchmark des solutions e-Commerce et souhaitons de nouveau partager avec un maximum de personne notre expertise permettant à l’ensemble de la communauté Magento d’optimiser et de développer leur sites. C’est pourquoi, nous avons créé une liste permettant de vérifier si un site Magento est sain ou non, qui nous a également permis, entre autres, de développer en interne un outil automatisé vérifiant tous ses points. Nous n’allons pas rendre disponible cet outil, mais nous allons partager la liste avec vous, afin que votre hébergeur ou intégrateur système puisse réaliser manuellement la même procédure. Vous pourrez ainsi anticiper et résoudre plus facilement les problèmes que vous pourriez rencontrer avec la plateforme.

 

Hébergement magento15 étapes pour vérifier la performance de Magento

Puisque nous hébergeons plus de 1200 sites utilisant Magento, nous avons créé une liste permettant de survivre à la créativité des intégrateurs systèmes et des clients. La voici :

Instance Magento

  • Modules / extensions : les installations Magento trop remplies avec beaucoup de modules étrangers, ont tendance à être lentes
    • Dans l’application ou le code, vérifiez ces trois référentiels :
      • Community : la partie du code où les extensions de marché sont stockées habituellement
      • Local : l’endroit où les intégrateurs systèmes sont censés mettre leur code
      • Magento: l’endroit où les modules/fonctionnalités initiales de Magento sont stockées
    • Un bon compromis est de ne pas avoir plus de 30 modules actifs. Quand cela est possible, vérifiez la qualité/impact performance de ces modules
  • Évidemment, il vous faut vérifier la configuration générale de Magento :
    • Dans un premier temps, les fichiers local.xml et enterprise.xml. Souvenez-vous, utilisez toujours un backend lent et structuré pour stocker vos informations de cache, ou celui-ci sera inactif/inutile. Les bons backends sont, par exemple : Redis, Database, File… N’UTILISEZ JAMAIS MEMCACHED COMME BACKEND LENT
    • Sondez la configuration de Magento à la recherche de core_config_data et vérifiez sa cohérence
    • Listez les magasins, vérifiez les produits stockés, ceux qui sont actifs, et listez les par magasins pour vérifier que votre Magento n’est pas alourdi par des produits inactifs
    • Vérifiez les paramètres du cache. Si FPC (Full page Cache) est présent (sur Magento Enterprise Edition), est-il activé (pour Magento 1.13 et plus ; avant cette version, cette étape est inutile) ? Vérifiez que tous les caches Block sont activés
  • Vérifiez les permissions des fichiers. Attention ! Même si la documentation Magento vous le demande, ne mettez jamais vos fichiers dans 777. C’est très mauvais et non nécessaire !

Base de données Magento

  • Vérification de la base de données. Vérifiez que les tables ne sont pas :
    • Fragmentées (pas plus de 50%)
    • Grossissant indéfiniment
    • Vérifiez en particulier ces tables à la recherche de contenu à vider ou à tronquer/archiver. Vous pouvez les vider ; cela aura une répercussion sur les stats ou autres, mais cela ne cassera pas le site. Vous pouvez au moins archiver la plupart sereinement :
      • databasdeTables CE Log : log_customer; log_quote; log_summary; log_summary_type; log_url; log_url_info (polluted by bots); log_visitor (same); log_visitor_info; log_visitor_online; sendfriend_log
      • Tables EE Log : enterprise_staging_log; enterprise_reminder_rule_log
      • Tables Import/export (only used during the import/export process, never flushed): dataflow_batch_export; dataflow_batch_import
      • Tables Archive : Report_compared_product_index; report_event; catalogsearch_result; catalogsearch_query; report_viewed_product_index; sales_bestsellers_aggregated_daily; sales_bestsellers_aggregated_monthly; sales_bestsellers_aggregated_yearly; enterprise_logging_event enterprise_logging_event_changes
      • Tables Index : index_event; index_process_event
      • Tables CE Cache & session : core_cache_tag; core_cache; core_session
      • Session EE : persistent_session

Tâches Cron de Magento

  • Vérifiez les tâches Cron internes et système programmées. Souvent, on pense à la tâche Cron système, déclenchée par Linux avec le daemon Cron. Cependant, Magento garde également une liste de tâches Cron internes, qui peut grossir, subir une erreur ou faire débuter toutes les tâches au même moment.

Logs Magento

  • Vérifiez les paramètres Magento à la recherche des logs. Sont-ils vidés ? Combien de temps sont-ils conservés ? Combien de jours sont sauvegardés ? etc…
  • Détectez les erreurs dans var/report, var/log/errors et var/log/exception, puisque la cause initiale des crashs applicatifs est souvent facile à identifier dans ces logs. Cela mène, en général, à une erreur 50X sur les frontaux
  • Vérifiez l’accès Apache et le log PHP Error pour vous assurer qu’ils n’ont pas d’erreurs 40X ou 50X, générallement dues à des crashs PHP
    Error 404
  • Vérifiez si le mode débug Magento est activé. C’est un tueur de performance
  • Vérifiez que les données sensibles client (e-mail, numéro de carte de crédit, etc) ne sont pas stockées dans les logs de Magento, et que ces logs ne sont pas dans 777… Au cas où. Cela arrive plus souvent que vous ne l’imaginez.

Templates Magento

  • Analysez combien de requêtes SQL sont déclenchées par le rendu de la page d’accueil. L’idéal est 0 (FPC et le cache Block font bien leur travail), la moyenne se situe à 40 ; au-delà de 80, vous aurez des problèmes. Vous pouvez activer le profiler Magento, pour une seule IP afin de ne pas surcharger le serveur, puis analyser les résultats
  • Analysez la santé du cache. Si le backend est vide, c’est mauvais ; s’il est surpeuplé (particulièrement sur le backend fichier), le site sera ralenti. Configurez le cache pour qu’il s’auto-invalide toutes les 24h, progressivement, clé par clé. Ne videz pas tout d’un coup inutilement
  • Vérifiez la qualité du template HTML avec validator.w3c.org et du CSS avec jigsaw.w3c.org
  • Vérifiez la qualité en lançant une évaluation Google Insight de la page
  • Vérifiez le contenu .htaccess, pour voir si personne n’a élevé la limite mémoire PHP à des valeurs folles comme 1GB, et si les headers Etags et Expire sont configurés correctement

Pour faire simple, cette liste permet de repérer d’où viennent les problèmes Magento. Elle vous aidera à mieux connaître votre plateforme et à éviter en amont ses éventuels bugs, ralentissements ou problèmes. C’est typiquement à partir de ces 15 points que nous avons développé notre outil interne évoqué en introduction. Ce sont les points de départ pour maintenir un site sain sous Magento ; cette liste est donc un bon guide de survie pour vous, e-Commerçants utilisateurs de cette technologie.

Nous espérons qu’elle vous sera utile !

Philippe Humeau
Philippe Humeau
Philippe a co-fondé NBS System en 1999. Après s’être concentré sur la sécurité, qu’il n’a jamais abandonnée, il se découvre une passion pour le ecommerce à partir de 2008. Tour à tour pentester, CTO, CCO puis CEO, son profil touche-à-tout l’a conduit à devenir directeur marketing et stratégie d’OT Group après notre intégration dans celui-ci.