Notre solution a donc été validée par Varien, société éditrice de Magento.

Retrouvez nos offres sur notre micro-site dédié.

http://www.hebergement-magento.net/

Magento Professional Partner Logo

©2012 Virtua Network Services. All Rights Reserved.

Aujourd’hui, nous vous présentons le résultat d’un comparatif entre notre hébergement Magento et celui d’un hébergement low-cost.

Nous avons installé la même version de Magento sur les deux hébergements. Nous avons activé les optimisations maximales possibles sur les deux solutions.

L’hébergement low-cost est un produit Suisse offert par un hébergeur reconnu à moins de CHF 200.– / an. Notre but n’étant bien évidemment pas de nuire à cet hébergeur nous tairons son nom.

Il faut bien garder en tête que nous comparons deux produits totalement différents : une solutions généraliste à petit prix, et une solution spécialement optimisée.

Nous avons ensuite utilisé une machine de test distante, sur un réseau séparé des deux hébergements, toujours pour offrir une comparaison la plus fair-play possible. Cette machine simulait des sessions humaines, avec de plus en plus d’utilisateurs en parallèle.

Voici un tableau présentant l’évolution du temps de réponse du site en fonction du nombre d’utilisateurs en parallèle :

Comparatif hébergements Magento (plus petit = meilleur)

Evolution du temps de réponse moyen en fonction du nombre de sessions simultanées

En abscisse : le nombre d’utilisateurs en parallèle

En ordonnée : le temps de réponse des pages.

En bleu : notre hébergement spécialisé Magento

En rouge : hébergement low-cost ou hébergement non spécialisé

Le temps de réponse de base est déjà largement plus lent sur la solution low-cost. La page est visualisée en moins d’une seconde chez nous, alors qu’elle prend déjà le double sur l’autre solution.

On atteint deux secondes de temps de chargement à partir de cinq utilisateurs sur la solution low-cost, alors que l’on n’a jamais atteind 1.3 secondes chez nous.

Nous avons arrêté à 40 utilisateurs parallèles car la solution low-cost ne répondait plus que des erreurs. Notre solution pouvait continuer à fonctionner.

Ce graphique, très parlant, démontre encore une fois la nécessité d’avoir un hébergeur spécialisé pour votre plateforme Magento : plus votre site met du temps à charger, plus vous perdez des clients potentiels. Différentes études ont montré que 100ms de temps de chargement supplémentaire = 1% de CA en moins. D’autre part, Google va très certainement intégrer la notion de temps de chargement comme facteur dans son moteur de recherche,  ceci étant déjà le cas pour les AdWords.

Au final, si l’hébergement spécialisé est indéniablement plus cher c’est bien parce que les prérequis de Magento sont importants, et qu’il faut une expertise plus poussée qu’un simple setup LAMP.

NB : nous avions vérifié que l’hébergement low-cost disposait bien d’un OPcode cache (xcache, eaccelerator, APC..).

©2012 Virtua Network Services. All Rights Reserved.

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

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

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

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

©2012 Virtua Network Services. All Rights Reserved.