Magento : impact des outils serveur de nouvelle génération sur ses performances

Introduction

Pour nos clients, mais aussi pour conserver notre niveau dans la veille technologique, nous nous tournons progressivement vers Magento pour les portails de e-commerce. En effet, Magento c’est d’abord un pas de plus dans les fonctionnalités par rapport à sa concurrence :

  • Installation simple
  • Entièrement personnalisable
  • Multiboutique (1 backend administration, plusieurs frontaux)
  • Processus de commande unifié
  • Expedition multi-adresses
  • Outils de marketing
  • Statistiques complètes
  • Recherche
  • Référencement naturel
  • Framework robuste (Zend)

Malheureusement, Magento c’est aussi ce qu’on appelle plus communément une « usine à gaz« . Et ce produit phare qui est tant apprécié par les webmarchands peut vite devenir un cauchemars à mettre en œuvre et à maintenir pour des administrateurs systèmes et réseaux. En effet, le portail est extrêmement lourd : même avec les optimisations recommandées par le site principal, les performances sont loin d’être au rendez-vous, et si vous prenez la chose à la légère, vous serez vite rattrapé par les limites de votre serveur, ce qui, il faut bien l’avouer, est particulièrement nuisible pour un site de e-commerce. Nous ne sommes pas les seuls à être confronté à ce problème et plusieurs astuces, tutoriels et conseils sont dors et déjà disponibles sur le net et nous espérons contribuer à cet effort collectif en publiant les résultats de nos benchmarks sur une configuration ‘tunée’, et ainsi tordre le cou à la réputation négative de Magento : oui, Magento est lourd, mais sur une configuration spécialisée il se comportera comme n’importe quel site marchand.

Présentation

Pour affronter ce géant nous avons sorti l’attirail lourd et utilisé de récentes technologies plutôt que d’anciens dinosaures :

  • Nginx / WebServer. Produit habituel : Apache
  • Varnish / Reverse Proxy. Produit habituel : Squid
  • php-fpm / PHP interpreter. Produit habituel : mod_php d’apache
  • eaccelerator / PHP OpCode Accelerator. Produit habituel : aucun, parfois Zend Optimizer
  • MySQL XtraDB / Database Engine. Produit habituel : MySQL MyISAM / InnoDB

Cet ensemble système est assez peu fréquent actuellement, et on le retrouve principalement sur des sites à très fortes charges. Sa mise en œuvre demande une certaine habitude, ce qui peut en dérouter plus d’un, surtout que les setups actuels basés sur Apache/MySQL/Squid, largement commentés, sont différents sur plusieurs points :

  • Premièrement, nginx ne gère pas ‘nativement’ le PHP : il utilise comme son confrère lighttpd une interface FastCGI pour communiquer avec les processus ‘stand-alone’ PHP.
  • Ensuite, du fait de cette ‘séparation’ des tâches, nginx peut parfaitement s’acquitter du contenu statique comme le ferait un reverse-proxy.
  • Enfin, l’établissement de ce type de setup demande beaucoup plus de temps du fait de la nécéssité d’un tuning élaboré sur chaques parties (nginx, PHP, MySQL…)

Nous avions déjà utilisé cette configuration dans un environnement de haute disponibilité, et cela avec succès : c’est donc logiquement que nous nous sommes posé la question : Quid de ce cocktail appliqué à Magento ? Et bien, nous allons partager avec vous cette expérience, en vous communiquant les résultats de nos tests de charge.

Cas de Varnish

Varnish peut être utilisé pour cacher du contenu dynamique car il implémente ESI. Cependant, Magento ne supporte actuellement pas ce type de caching, il faut donc se rabattre sur les fonctionnalités ‘basiques’ de Varnish. Son ajout permet aussi de décharger le ou les serveur(s) WWW situé(s) en aval. Cela présente donc des avantages qui font toute la différence lors de charges systèmes importantes. C’est un ajout particulièrement utile pour un serveur web relativement lourd et lent comme Apache, moins utile pour un produit léger et rapide comme Nginx. IMPORTANT Notez que pour donner un sens aux résultats de nos benchmarks, Varnish n’a pas été activé : le but ici est de mesurer l’impact de Magento sur les différents composants systèmes. Nous y faisons référence car la présence d’un reverse-proxy / cache nous paraît importante pour de gros sites de e-commerce : il contribue très largement à donner cette sensation de fluidité à l’utilisateur final.

Fonctionnement

infrastructure magento

Hardware

Serveur A 4cores : 1 x Intel(R) Xeon(R) CPU X3210 @ 2.13GHz 2GB RAM Serveur B 8cores : 2 x Quad-Core AMD Opteron(tm) Processor 2376 8GB RAM Box1 et Box2 : IBM thinkpad X41 Dothan 1,5Ghz Network : Gigabit Ethernet OS Ubuntu 8.04 LTS 64bits Linux 2.6.24-23-server #1 SMP Mon Jan 26 01:36:05 UTC 2009 x86_64 GNU/Linux

Software

(Serveurs) PHP 5.2.8 (+ fpm 0.9.6.3 + suhosin) eaccelerator 0.9.5.3 MySQL 5.1.33 (+ percona's XtraDB 1.0.2-3) - OU - MySQL 5.0.51a InnoDB Nginx 0.6.36 (Générateurs de charge) Funkload A noter que les sessions Magento sont en tmpfs.

Lexique

Connexions Simultanées : Nombre de connexions qu’un serveur peut supporter au même instant. Temps de réponse moyen ou Page Response Time (PRT) : Délai d’attente du chargement des pages (moyenne)

Méthode

Les deux machines de charges (Box 1 et Box 2) générent des réquêtes en parallèle sur le front WWW, composé soit :

  • de Magento 1.2.1 + Sample Data 1.2.0
  • de Magento 1.3 + Sample Data 1.2.0

Chaque machine va effectuer un parcours sur le site. Ce parcours est le suivant : GET /index.php/customer/account/login/ POST /index.php/customer/account/loginPost/ GET /index.php/ GET /index.php/catalog/category/view/s/furniture/id/10/ GET /index.php/catalog/category/view/s/bedroom/id/23/ GET /index.php/catalog/product/view/id/42/s/barcelona-bamboo-platform-bed/category/23/ GET /index.php/customer/account/logout/ GET /index.php/ Traduction : l’utilisateur se loggue, parcourt le site et se déloggue Ces deux machines de tests peuvent générer sans tortiller 200 connexions simultanées chacune, ce qui porte le test final à 400 connexions parallèles sur le site. Il est important que cette session ne contenant aucun fichier statique (.jpg, .css, .js, …) ne correspond en rien en une session classique, et ne permet pas de mettre en valeur les avantages de Nginx par rapport à Apache. Nous essayons uniquement de voir les effets sur les pages lourdes, en php.

Benchmarks

Test de référence : Le test de référence est réalisé sur la version 1.2.1 de Magento sur le serveur A. Dans un premier temps la DB n’est pas externalisée sur un autre serveur nous avons donc :

  • Nginx
  • Php-fpm
  • Eaccelerator
  • MySQL 5.0 + InnoDB

Magento 1.2.1 QuadCores Ce test de référence indique que pour un 120 CS, nous obtenons un PRT de 1,5 seconde. Ceci constitue déjà un bon score, mais continuons. Test avec le 8coeurs : Avec la meme configuration mais ‘transplantée’ sur le serveur B (8cores), le gain est appréciable : Magento 1.2.1 sur 2*QuadCores Ainsi, le seuil des 200 CS est dépassé pour un PRT inferieur à 2 secondes ! Gain par rapport au Test de référence : environ 50% au mieux. Premier constat : l’apport de processeurs puissants augmente sensiblement les performances. Test de la version 1.3 de Magento Lors de sa sortie, l’équipe de Magento a présenté cette version comme étant plus performante que la précédente. Nous avons voulu vérifier ces dires en comparant les deux versions sur la meme configuration système bien entendu. Magento 1.3 avec 2*QuadCore Et en effet : nous obtenons un PRT de 2s pour 280CS ! Ce qui nous donne un gain maximum de 50% par rapport à la version précédente (1.2.1). Notez que le test présente un pic dû à une surcharge ponctuelle du serveur (Cron etc..). Nous aurions pu relancer le test, mais nous avons trouvé intéressant de montrer l’impact que peut produire un processus externe (service) sur les performances : pensez bien à nettoyer vos serveurs de programmes superflus ! Passage à MySQL 5.1 et XtraDB Dans certains cas, le passage de la version 5.0 à la 5.1 de MySQL donne des gains importants. Dans notre cas, nous avons voulu pousser les performances en y ajoutant le moteur XtraDB de Percona.Magento 1.3 Database Engines comparison Comme vous pouvez le constater, le gain est bien moins impressionant : environ 10% au mieux, et encore, lors d’une charge importante. Nous expliquons ceci du fait que les CPU sont déjà bien surchargés et ne permettent pas de donner toute sa dimension au tuning effectué sur la base de données : pour se faire nous devons externaliser ce service sur un autre serveur… Sortie de la database : tests sur 2 serveurs Il est important de noter que nous passons d’un mode ‘socket’ au mode ‘IP’ de MySQL, ce qui normalement engendre une baisse de performances de l’ordre de 10%. Mais dans notre cas, du fait du tuning sur la database, nous arrivons tout de meme à obtenir un gain positif par rapport au précédent test : 10% au mieux. Nous remarquons aussi que plus le serveur WWW est chargé, plus ce gain va en augmentant. Magento 1.3 with(out) external database server Test final comparé au test de référence Il est temps de resumer les optimisations faites :

  • Passage au 8cores
  • Passage version 1.3
  • Sortie de la DB sur un autre serveur
  • Remplacement de InnoDB par XtraDB et de MySQL 5.0 par la version 5.1

Magento NG + optimized server Graphiquement, le gain est évident ! Pour 2s, nous obtenons un gain de 120% qui est du en grande partie au passage de la version 1.2.1 vers la 1.3 et du 4 coeurs vers le 8 coeurs.

BONUS : comparatif avec les autres solutions existantes

Entre le debut des benchmarks et l’écriture de cet article, il y a eu 2 événements majeurs dans le monde de Zend/Magento :

  • Sortie de la version 1.3.1
  • Sortie de Zend Server 4.0

La version 1.3.1 est une update mineure de Magento, mais apporte aussi ses améliorations. La sortie de Zend Server est par contre très interéssante car il arrive second dans nos tests, juste derrière notre propre solution, jusqu’au moment où surchargé, il ne génère que des erreurs. Apache vs Zend vs Nginx Nous avons aussi testé des solutions « de base » :

  • En vert : apache + mod_php d’Ubuntu 8.04 server
  • En jaune : apache + mod_php d’Ubuntu 8.04 server + e-accelerator
    • MySQL n’est pas le ‘bottleneck’ sur l’environnement : les CPUs sont surchargés bien avant par la lourdeur du portail.
    • Les optimisations importantes au niveau code sont toujours possibles : le passage de la version 1.2.1 -> 1.3 apporte 50% dans certains cas !
    • Le combo nginx / php-fpm est le plus performant et le plus endurant
    • les autres solutions génèrent quantité d’erreurs très rapidement alors qu’nginx continue à fonctionner bien plus longtemps, même si les réponses sont plus lentes
    • Dans nos tests, nginx n’a jamais saturé la mémoire et a utilisé une taille fixe durant tous les tests, alors que la consommation d’apache est proportionnelle au nombre de requêtes, et finit par saturer la mémoire disponible, poussant au « swap of death » des pauvres serveurs
    • Il n’est pas anodin non plus de passer d’un 4 coeurs à un 8 coeurs dans ce type d’application
    • - MySQL n’est pas le ‘bottleneck’ sur l’environnement : les CPUs sont surchargés bien avant par la lourdeur du portail.
    • - Les optimisations importantes au niveau code sont toujours possibles : le passage de la version 1.2.1 -> 1.3 apporte 50% dans certains cas !
    • - Pour des sites à fort trafic (ce qui est souvent le cas avec Magento), il devient intéressant de se passer d’Apache pour des infrastructures plus modulaires, comme nginx, mais pourquoi pas lighttpd avec PHP en FastCGI.
    • - Mettre un 8cores pour Magento sur un OS 64bits apporte son lot de performances.
  • Remarquez les points d’arrets : au-delà de cette limite, des erreurs serveurs ont été observées (code 500, pas de réponse…), ce qui signifie que le site ne fonctionne plus ! A ce petit jeu, nginx, coeur de notre solution, s’en sort beaucoup mieux, et continue à fonctionner sans générer d’erreur jusqu’au bout.

    Conclusion

    Pour nous, ces tests sont importants car ils montrent que :

    Ces benchmarks nous ont montré que Magento requiert des compétences spécialisées pour obtenir un portail e-commerce fluide. Contrairement à un hébergement classique, les résultats s’obtiennent en paufinant non seulement la configuration système comme nous avons pu le voir ici, mais aussi en customisant la partie applicative. Au total, c’est un travail minutieux qu’il faut faire tout autour du portail, véritable savoir-faire que nous possedons, et qui est la seule méthode efficace à notre connaissance pour que Magento donne de toute sa puissance !

    Rendez-vous sur http://www.hebergement-magento.net/ pour plus d’informations sur notre offre d’hébergement.

Mots clés: , , , , , , , , , , , , , , ,

articles associés

6 réponses pour “

  1. Adexos dit :

    Bonjour,

    Nous travaillons sur Magento pour plusieurs clients, nous n’avions jamais trouvé de tests de performance aussi complet.

    Très bon boulot !

  2. [...] à la mise en place de notre solution ultra optimisée d’hébergement de la solution e-commerce Magento, nous sommes à présent un des rares « Magento [...]

  3. Kerry Dicks dit :

    Votre blog est d’une grande qualite . Je suis devenu un lecteur assidu.

  4. Nelson dit :

    Vous pouvez faire la même chose avec Prestashop ou cela n’es pas nécessaire?

  5. marcel dit :

    Bonjour,

    Nous pouvons proposer les mêmes services pour Prestashop, même si de base les performances sont largement meilleures, dès que vous atteignez un nombre de visites élevé vous pouvez souffrir de ralentissements très désagréables pour vos acheteurs potentiels, et pour garantir une haute disponibilité et éviter tout soucis en cas de panne hardware par exemple, nos solutions sont à conseiller.

Laisser une réponse

Your browser doesn't work with css