©2012 Virtua Network Services. All Rights Reserved.

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

©2012 Virtua Network Services. All Rights Reserved.

Virtua dispose depuis plus de dix ans de ses propres serveurs, hébergés dans un local optimisé à proximité de nos bureaux.

 
Nous gérons entièrement la fourniture du réseau, du câblage à la gestion BGP4+ multi peer, offrant une indépendance totale, des performances de pointes et une redondance complète. Nous offrons des solutions de qualité élevée adaptée à tout besoin, de simples serveurs indépendants à des solutions complexes totalement redondantes et hautement sécurisées.

 
Nous offrons des services de consulting pour l’aide à l’élaboration de votre infrastructure ainsi que pour sa mise en fonction. Nous avons par exemple entièrement imaginé, mis en place, optimisé et continuons de maintenir la plateforme complète de Swissfriends.ch, le plus grand site Suisse de rencontres, gérant plus de 150’000 membres.

2. Hébergement

2.1. Informations générales

Notre centre d’hébergement se trouve dans les locaux de la SEFA (Société Electrique des Forces de l’Aubonne) à Aubonne.

 
Cette localisation amène différents avantages :

• - Grâce à notre partenaire énergétique, Virtua est l’une des seules entreprises à pouvoir proposer un hébergement alimenté par une énergie renouvelable à la norme TUV EE01. Nous soucier de l’avenir de la planète est un choix que nous avons fait. Cela ne nous empêche pas de prendre en compte les besoins de nos clients. Ainsi, nos serveurs ne dépendent pas d’une source électrique extérieure : ils sont alimentés, refroidis, sauvegardés 24 heures sur 24, sept jours sur sept grâce à l’énergie hydraulique produite par la SEFA elle-même. Virtua prouve que l’on peut être hautement efficace et profondément respectueux de la nature.
• - Ce lieu est stratégiquement posé sur trois nœuds totalement indépendants de fibres optiques : le réseau Fibrelac (autoroute), EOS (lignes électriques) et celui de l’état de Vaud. Ainsi, contrairement à la plupart de nos concurrents, nous sommes alimentés physiquement par des réseaux distincts et autonomes. Une coupure d’un canal de fibre n’entraîne qu’une perte partielle d’accès sans incidence visible par les internautes.
• - Proximité immédiate de nos bureaux, le centre se trouvant à moins d’un kilomètre de nos bureaux, nous pouvons intervenir immédiatement en cas de problème grave.

2.2. Sécurité physique

Le centre d’hébergement n’a pas d’accès direct depuis l’extérieur, il s’agit d’un « bunker » fermé, situé au centre du bâtiment SEFA à Aubonne. En journée, le contrôle physique d’accès est assuré par le personnel sur place, durant les autres périodes, un service de piquet ne donne l’accès qu’après contrôle physique des autorisations. De plus, un système vidéo contrôle la pièce 24h/24, 7j/7.

2.3. Climatisation

Afin de garantir une performance optimale, la pièce est maintenue à une température de 23°C et une humidité relative de 50% par un système de climatisation industrielle.

2.4. Alimentaire électrique

Tous les clients bénéficient d’une alimentation redondante haute capacité, stable et fiable, évolutive en cas d’expansion future. L’alimentation est maintenue indéfiniment, avec des systèmes d’alimentation sans coupure industriel (UPS) et l’accès direct au système de production hydraulique de la SEFA. L’alimentation électrique y a été assurée à 100% durant les 24 derniers mois.

2.5. Fedd internet

Nous avons mis en place un système totalement redondant d’accès à Internet. Notre système de routage basé sur BGP4 nous a permis d’offrir 100% d’accès sur les 12 derniers mois. Nous avons de plus suffisamment de bande passante pour absorber la disparition d’un lien sans subir de ralentissement notable.

 
Schéma de principe :

 

3. Offre d’hébergement sur serveur dédié

3.1. Hébergement

L’hébergement dédié comprend :

• - Un emplacement 1U 19′ dans armoire privée Virtua
• - 100 Gbps de traffic mensuels
• - Port 100Mbit/ directement sur notre backbone
• - 2 IP’s statiques (plus sur demande)
• - Service DNS primaire et secondaire pour 4 noms de domaine (plus sur demande)
• - Statistiques de consommation "temps réel"
• - Backup réseau 30Gb
• - Reboot distant suivant hardware

Frais de mise en service : CHF 180.- Frais mensuels : CHF 480.-

3.2. Support

Les services hébergés étant sur le même réseau que nos machines de production, vous profitez de notre infrastructure maintenue par nos services.

 
Nous disposons d’un système de monitoring serveur distribué international et d’un service de piquet 24h/24, 7j/7

 
Support niveau 2 et 3 inclus :

• - support téléphonique pendant les heures de bureau
  (LU-VE, 8:00-12:00/14:00-18:00, réponse dans les 4 heures max).

Inclus dans les frais d’hébergement

Suivant la demande, nous pouvons facturer CHF 180.- de l’heure entamée si le problème n’est en aucun cas imputable à nos services.

3.2.1. Support optionnel

Accès direct au système de piquet 24/24, 7j/7, réponse dans les quatre heures

Frais annuel : CHF 7’200.-

3.3. Options

3.3.1. Hardware

Vous pouvez nous fournir votre propre serveur. Dans le cas contraire, nous pouvons proposer tout type de machine, comme par exemple le serveur suivant : HP ProLiant DL320 G5 : (Suivant les disponibilités, la machine peut changer)

• - Quad-Core Xeon E3210 3Ghz
• - 2Gb RAM
• - 2X160Gb harddisk RAID-1 (hotswap)
• - Garantie 3 ans

Prix : CHF 1’890.-

Le support hardware est garanti par le producteur.

3.3.2. Monitoring "local"

Nous proposons un monitoring de la "santé" de votre site, notre système contrôle régulièrement les éléments suivants :

• - Espace disque disponible
• - Charge cpu
• - Problèmes disques (raid)
• - Présence des applications nécessaires
• - Réponse au « ping » réseau
• - Réponse du site web
• - Réponse du serveur mysql

En cas d’anomalie, une alerte est immédiatement envoyée par sms et email à nos services. Le détail est de plus accessible via Internet, sur interface protégée.

Frais de mise en service : offerts
Frais mensuels : CHF 60.-

3.3.3. Monitoring "distant"

Nous disposons de serveurs à l’étranger (France et Etats-Unis) depuis lesquels nous contrôlons la bonne disponibilité de votre site (http, https)

En cas d’anomalie, une alerte est immédiatement envoyée par sms et email à nos services.

Frais de mise en service : offerts
Frais mensuels : CHF 80.-

3.3.4. Firewall hardware / UTM

Nous proposons différentes solution de sécurisation adaptable à vos besoins, nous pouvons fournir les produits suivants :

• - Bee-ware
• - Cisco
• - Fortinet
• - Watchguard

3.3.5. Firewall Software

A la place de la solution précédente, nous pouvons proposer la mise en place d’un firewall software, intégré à Linux. Bonnes performances et sécurisation suffisante.

Frais de mise en service : CHF 180.–
Frais mensuels : offerts

3.3.6. Load-Balancing / Haute disponibilité

Nous avons développé différentes solutions de load-balancing et haute disponibilité pour site à haute charge. Depuis plus de cinq ans, ces technologies assurent à nos clients de grande échelle une disponibilité optimale.

Ces options étant très liées au fonctionnement du site, elles nécessitent des offres sur mesure. N’hésitez pas à nous contacter pour plus de détails.

Prix sur demande

©2012 Virtua Network Services. All Rights Reserved.