Introduction

We at Virtua are aware of the advantages that a solution like Magento can provide. This product brings brand new perspectives to the e-commerce world :

• Simple installation
• Fully customisable
• Multiboutique (1 administration backend, many frontends)
• Unified Ordering Process
• Multi addresses deliveries
• Marketing tools
• Full statistics
• Internal search engine
• SEO optimized
• Robust framework (Zend)

Unfortunately, Magento it is also what is called more commonly a “gas works “. And this leading product which is appreciated so much by the e-sellers can quickly become nightmares to be implemented and to maintain for system administrators and networks.

Indeed, the portal is extremely heavy: even with the optimizations recommended by the official site, the performances are far from being great, and if you take the thing with the light one, you will quickly be caught up with by the limits of your server, which is particularly harmful for an e-commerce site.

We are not the only ones with being confronted with this problem and several easy ways, tutorials and already available on the Net and we hope to contribute to this collective effort by publishing the results of our benchmarks on a tuned configuration, and thus to twist the neck with the negative reputation of Magento: yes, Magento is heavy, but on a specialized configuration it will behave like any trader site.

PRESENTATION

To face this giant we took our best weapons and used recent technologies rather than old dinosaurs:

• Nginx/WebServer. Usual product: Apache
• Varnish/Proxy Reverse. Usual product: Squid
• php-fpm/PHP to interpret. Usual product: mod_php of apache
• eaccelerator/PHP OpCode Accelerator. Usual product: no, sometimes Zend Optimizer
• MySQL XtraDB/Database Engine. Usual product: MySQL MyISAM/InnoDB

This system unit is currently rather not very frequent, and one finds it mainly on sites with very high loads. Its implementation requires a certain know-how because unlike the current setups based on Apache/MySQL/Squid that are largely documened, there are several different points:

• Firstly, nginx does not manage PHP natively : it uses like its fellow-member lighttpd a FastCGI interface to communicate with the stand-alone PHP processes.
• Then, because of this separation of the tasks, nginx can perfectly serve static contents as a reverse-proxy would do it.
• Lastly, establishment of this type of setup request much more time because of need of a tuning elaborate on each parts (nginx, PHP, MySQL…)

We had already successfully used this configuration in an high availability environment : it is thus logically that we put ourselves the question: Quid of this cocktail applied to Magento? And well, we will share with you this experiment, by communicating to you the results of our load tests.

Varnish’s case

Varnish can be used for caching dynamic contents because it implements ESI. However, Magento currently does not support this type of caching, it is thus necessary to be folded back on the basic functionalities of Varnish. Its addition also makes it possible to lower  the load of the backend www server(s). It is a particularly useful addition for a relatively heavy and slow Web server like Apache, less useful for a light and fast product like Nginx.

IMPORTANT Please note that in order to give a direction to the results of our benchmarks, Varnish was not activated: the goal here is to measure the impact of Magento on the various components systems. We refer there because the presence of a reverse-proxy/cache appears important to us for large e-commerce sites : it very largely contributes to give a feeling of fluidity to the end user.

Schema

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

(Servers) 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 (load tool) Funkload

GLOSSARY

Concurrent Connections: Number of connections that a server can handle at the same instant t.
Average response time or PRT : Timeout waiting for the loading of pages (average)

METHOD

Both load machines (Box 1 and Box 2) generate parallel requests on the front WWW, which is composed either of :

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

Each machine is going to do the same requests on the site. The path is the next one 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/

Each of these two machines can generate without trouble 200 concurrent connections, which gives 400 concurrent connections on the final test.

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

Nous retenons qu’avec un PRT 1,5 seconde nous obtenons 120 CS. Gain avec le 8core : 50% 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 ! * Passage a la version 1.3 de Magento 50% Le test de la version 1.3 est effectue sur le serveur B. Le test presente un pic sans doute du une surcharge ponctuelle du serveur (Cron etc..), nous avons decide de le laisser car ce type de cas est souvent present en production, et simule un action sur un autre service… Quoiqu’il en soit, le gain avec la nouvelle version est aussi important qu’avec le passage d’un 4core a un 8core ! PRT de 2secondes pour 280 CS ! * Passage a MySQL 5.1 et XtraDB 10% Nous passons a des gains positifs mais largement moins impressionants : <1.3_8c_innodb_vs_xtradb.png> On remarque que l’ecart se creuse lors d’une charge importante et tend a s’augmenter.. * Sortie de la database : tests sur 2 serveurs 10% Le gain n’est encore une fois pas enorme. Plus le serveur sera charge, plus ce gain augmentera. <1.3_8c_xtradb_in_vs_out.png> * Test final compare au test de reference Si l’on compare les optimisations systemes qui ont ete faites : <1.2.1_4c_vs_1.3_8c.png> L’ecart est enorme, car si l’on resume : Pour 2s, Gain de 120% que l’on attribue a 80% au passage d’un 8cores et au passage a la version Magento 1.3

Chez Virtua, nous sommes conscients des avantages que peut apporter une solution comme Magento. En effet, ce produit ammène un renouveau dans le monde du e-commerce :

• Installation simple
• Entièrement personnalisable
• Multiboutique (1 backend administration, plusieurs frontaux)
• Processus de commande unifié
• Expedition multi-adresses
• Outils de marketing
• Statistiques completes
• Recherche
• Referencement naturel

Malheureusement, Magento c’est aussi ce qu’on appelle plus communément une “usine à gaz”. Et ce produit phare qui est tant apprecié par les managers peut vite devenir un cauchemard à mettre en oeuvre et à maintenir pour des administrateurs systèmes et réseaux. En effet, le portail est extremement 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 a ê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 apportant notre pierre à l’édifice en publiant les résultats de nos benchmarks sur une configuration ‘tunée’.

PRESENTATION

Pour affronter ce géant nous avons sorti l’attirail lourd :

• Nginx / WebServer
• Varnish / Reverse Proxy
• php-fpm / PHP interpreter
• eaccelerator / PHP OpCode Accelerator
• MySQL XtraDB / Database Engine

Cet ensemble système est assez peu fréquent actuellement, et on le retrouve principalement sur des sites à fortes charges. Sa mise en oeuvre demande une certaine habitude, ce qui peut en derouter 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.

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. De plus, il permet 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 contraintes systèmes élevées. 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.

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 (Generateurs de charge) Funkload

LEXIQUE

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

METHODE

Les deux machines de charges (Box 1 et Box 2) générent des réquêtes en parallèle sur le front WWW Le front WWW est 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/ 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.

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

Nous retenons qu’avec un PRT 1,5 seconde nous obtenons 120 CS. Gain avec le 8core : 50% 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 ! * Passage a la version 1.3 de Magento 50% Le test de la version 1.3 est effectue sur le serveur B. Le test presente un pic sans doute du une surcharge ponctuelle du serveur (Cron etc..), nous avons decide de le laisser car ce type de cas est souvent present en production, et simule un action sur un autre service… Quoiqu’il en soit, le gain avec la nouvelle version est aussi important qu’avec le passage d’un 4core a un 8core ! PRT de 2secondes pour 280 CS ! * Passage a MySQL 5.1 et XtraDB 10% Nous passons a des gains positifs mais largement moins impressionants : <1.3_8c_innodb_vs_xtradb.png> On remarque que l’ecart se creuse lors d’une charge importante et tend a s’augmenter.. * Sortie de la database : tests sur 2 serveurs 10% Le gain n’est encore une fois pas enorme. Plus le serveur sera charge, plus ce gain augmentera. <1.3_8c_xtradb_in_vs_out.png> * Test final compare au test de reference Si l’on compare les optimisations systemes qui ont ete faites : <1.2.1_4c_vs_1.3_8c.png> L’ecart est enorme, car si l’on resume : Pour 2s, Gain de 120% que l’on attribue a 80% au passage d’un 8cores et au passage a la version Magento 1.3

Chez Virtua, nous sommes conscients des avantages que peut apporter une solution comme Magento. En effet, ce produit ammène un renouveau dans le monde du e-commerce :

• - 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éferencement naturel

Malheureusement, Magento c’est aussi ce qu’on appelle plus communément une “usine à gaz”. Et ce produit phare qui est tant apprecié par les managers peut vite devenir un cauchemard à mettre en oeuvre 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’.

Présentation

Pour affronter ce géant nous avons sorti l’attirail lourd :

• - Nginx / WebServer
• - Varnish / Reverse Proxy
• - php-fpm / PHP interpreter
• - eaccelerator / PHP OpCode Accelerator
• - MySQL XtraDB / Database Engine

Cet ensemble système est assez peu fréquent actuellement, et on le retrouve principalement sur des sites à fortes charges. Sa mise en oeuvre 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.

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

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 (Generateurs de charge) Funkload

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 Le front WWW est 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.

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

Nous retenons qu’avec un PRT 1,5 seconde nous obtenons 120 CS.   Test avec le 8core : 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. Test de la version 1.3 de Magento Le test de la version 1.3 est effectué sur le serveur B. Le test présente un pic sans doute dû à une surcharge ponctuelle du serveur (Cron etc..), nous avons décidé de le laisser car ce type de cas est souvent présent en production, et simule une action par un autre service sur le serveur… Quoiqu’il en soit, le gain avec la nouvelle version est aussi important qu’avec le passage d’un 4core a un 8core ! PRT de 2s pour 280 CS ! Gain par rapport à la version 1.2.1 : environ 50% au mieux Passage à MySQL 5.1 et XtraDB Nous passons à des gains positifs mais largement moins impressionants : environ 10% au mieux. On remarque que l’écart se creuse lors d’une charge importante et tend à s’augmenter.. Sortie de la database : tests sur 2 serveurs Le gain n’est encore une fois pas énorme : environ 10% au mieux. Plus le serveur est chargé, plus ce gain augmente. Test final comparé au test de référence Si l’on compare les optimisations systemes qui ont ete faites :

• - Passage au 8cores
• - Passage version 1.3
• - Sortie de la DB sur un autre serveur
• - Remplacement de InnoDB par XtraDB

Pour 2s, Gain de 120% que l’on attribue a 80% au passage d’un 8cores et au passage à la version Magento 1.3

Conclusion

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

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

Chez Virtua, nous sommes conscients des avantages que peut apporter une solution comme Magento. En effet, ce produit ammène un renouveau dans le monde du e-commerce :

• Installation simple
• Entièrement personnalisable
• Multiboutique (1 backend administration, plusieurs frontaux)
• Processus de commande unifié
• Expedition multi-adresses
• Outils de marketing
• Statistiques completes
• Recherche
• Referencement naturel

Malheureusement, Magento c’est aussi ce qu’on appelle plus communément une “usine à gaz”. Et ce produit phare qui est tant apprecié par les managers peut vite devenir un cauchemard à mettre en oeuvre et à maintenir pour des administrateurs systèmes et réseaux. En effet, le portail est extremement 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 a ê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 apportant notre pierre à l’édifice en publiant les résultats de nos benchmarks sur une configuration ‘tunée’.

PRESENTATION

Pour affronter ce géant nous avons sorti l’attirail lourd :

• Nginx / WebServer
• Varnish / Reverse Proxy
• php-fpm / PHP interpreter
• eaccelerator / PHP OpCode Accelerator
• MySQL XtraDB / Database Engine

Cet ensemble système est assez peu fréquent actuellement, et on le retrouve principalement sur des sites à fortes charges. Sa mise en oeuvre demande une certaine habitude, ce qui peut en derouter 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.

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. De plus, il permet 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 contraintes systèmes élevées. 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.

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 (Generateurs de charge) Funkload

LEXIQUE

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

METHODE

Les deux machines de charges (Box 1 et Box 2) générent des réquêtes en parallèle sur le front WWW Le front WWW est 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/ 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.

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

Nous retenons qu’avec un PRT 1,5 seconde nous obtenons 120 CS. Gain avec le 8core : 50% 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 ! * Passage a la version 1.3 de Magento 50% Le test de la version 1.3 est effectue sur le serveur B. Le test presente un pic sans doute du une surcharge ponctuelle du serveur (Cron etc..), nous avons decide de le laisser car ce type de cas est souvent present en production, et simule un action sur un autre service… Quoiqu’il en soit, le gain avec la nouvelle version est aussi important qu’avec le passage d’un 4core a un 8core ! PRT de 2secondes pour 280 CS ! * Passage a MySQL 5.1 et XtraDB 10% Nous passons a des gains positifs mais largement moins impressionants : <1.3_8c_innodb_vs_xtradb.png> On remarque que l’ecart se creuse lors d’une charge importante et tend a s’augmenter.. * Sortie de la database : tests sur 2 serveurs 10% Le gain n’est encore une fois pas enorme. Plus le serveur sera charge, plus ce gain augmentera. <1.3_8c_xtradb_in_vs_out.png> * Test final compare au test de reference Si l’on compare les optimisations systemes qui ont ete faites : <1.2.1_4c_vs_1.3_8c.png> L’ecart est enorme, car si l’on resume : Pour 2s, Gain de 120% que l’on attribue a 80% au passage d’un 8cores et au passage a la version Magento 1.3