S’il est désormais acquis pour tous (ou presque) que Magento offre toute la richesse fonctionnelle requise pour des sites e-commerce professionnels exigeants, il existait peu d’études approfondies sur sa capacité à accompagner les projets les plus ambitieux en termes de volumétrie, et nous étions fréquemment interrogés sur cette question.  Magento peut-il  gérer un catalogue de plusieurs millions d’articles ?  Une fréquentation de plus de 20 millions de visites par mois mois ?   Plusieurs milliers de commandes à l’heure ?

La réponse à cette question dépend évidemment d’un certain nombre de paramètres pas forcément liés directement à la qualité intrinsèque de Magento (qualité des développements, infrastructure d’hébergement etc…) Toutefois, si l’on part du postulat que toutes les bonnes pratiques sont respectées à tous les niveaux, qu’est réellement capable de faire Magento?

Pour y répondre de manière factuelle, nous avons mené sur plusieurs semaines, une grande campagne de tests de charge, mobilisant jusqu’à une douzaine de serveurs octo-cœurs, déroulant des scénarios complets et représentatifs d’un trafic réel, sur plusieurs jours de charge.

Nous avons compilé ces résultats et procédé à quelques analyses présentées dans un document téléchargeable ici : http://factory.clients.smile.fr/docs/magento-performances_et_scalabilite.pdf

Quelques mots sur la démarche

L’infrastructure et les scénarios de tests mis en œuvre ont pour objectif de mesurer plusieurs indicateurs :

• les temps de réponse des principaux écrans de navigation dans un contexte de très forte charge
• la capacité de service nominale d’un serveur et la scalabilité d’une architecture multi-serveurs
• le trafic supportée en fonction du nombre de frontaux
• le nombre de commandes et de mise au panier par heure en fonction du nombre de frontaux
• l’endurance de la plateforme sur une période de surcharge de 8h consécutives

Le document présente l’ensemble de l’architecture mise en oeuvre ainsi que les adaptations apportées à Magento pour pouvoir supporter de telles charges.

Alors, ça donne quoi?

En synthèse, la plateforme Magento a présenté un bon comportement en charge et une excellente extensibilité.

Les temps de réponse unitaires sont excellents pour les pages qui utilisent pleinement le dispositif de cache, et sont plus élevés pour les pages de mise au panier ou de confirmation de commande. Un aspect important des choix d’architecture logicielle de Magento est de solliciter principalement la CPU des frontaux, et assez peu la base de données.   C’est cette caractéristique qui permet une très bonne extensibilité, c’est-à-dire la capacité à mettre en place une plateforme à très haute capacité d’accueil par simple ajout de serveurs.   Cette extensibilité permet de faire monter en puissance une plateforme au fur et à mesure que son succès se confirme, sans rupture ni grande migration.

Cette campagne de tests démontre qu’une plateforme Magento bien conçue peut accueillir 28 millions de visites par mois, en servant jusqu’à 800 pages par seconde aux heures de pointe.

La base de données quant à elle, arrive à servir 20 serveurs frontaux en conservant une charge acceptable. Au delà, il faudra commencer à réfléchir à d’autres pistes d’optimisation.

Ce qu’il faut retenir

Notons, pour fixer les idées, que ces 28 millions de visites / mois, associées à une hypothèse de taux de transformation de 2% correspondent, pour un panier moyen de 20 €, à un CA mensuel de 22 M€, et pour un panier moyen de 100 €, à un CA mensuel de 112 M€.   Il y a peu d’acteurs dans le monde dans cette catégorie.

—————-

Conclusion

Beaucoup de chemin a été fait depuis les premières versions de Magento qui souffraient, il faut bien le reconnaître, de quelques soucis de performances. Aujourd’hui, la donne a changé et Magento n’a définitivement pas à rougir face aux mastodontes du e-commerce sur cette question de la scalabilité et des performances. Et ce que l’on sait aujourd’hui de Magento 2 qui nous arrivera l’année prochaine nous laisse espérer des résultats encore meilleurs…

Quand on vous dit que la vitesse ca change tout, c’est plus facile de le mesurer…

Eh bien pour les pro de Google Analytics, c’est maintenant faisable. Il faut comprendre que mesurer la vitesse de chargement d’une page, c’est très complexe. Déjà la définition même de temps de chargement n’est pas la même selon que l’on considère le moment ou la page est peuplée, la page est réellement active, on a finit tous les chargement, y compris les deferals etc…

La Google Team bosse actuellement sur le projet AFT, Above the Fold Time. C’est une nouvelle tentative de définition, assez maligne d’ailleurs, la conférence était intéressante.

Comment ca marche ?

Le plus beau, c’est que c’est simplissime. Il suffit d’ajouter une ligne dans votre tag Analytics de page web, celle en orange ci-dessous :

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-X']);
_gaq.push(['_trackPageview']);
_gaq.push(['_trackPageLoadTime']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>

Vous vous posez encore des questions ? http://www.google.com/support/analyticshelp/bin/answer.py?hl=fr&answer=1205784

Les pros d’analytics vont donc pouvoir coupler les paramètres qui vont bien, vitesse de chargement et taux de conversion par exemple. Cela va nous ouvrir un nouveau monde de statistiques, de métriques, qui vont être très pertinentes je pense.

Je vais en parler avec mes amis qui font de la SEO chez Blog Ecommerce, Isobar et Cybercité pour voir si on ne peut pas faire une étude un petit peu approfondie sur le sujet.

Dans le cadre d’un benchmark de site Web, de test de charge pour être plus précis, que faut il prendre en compte et pourquoi ? Que ce soit un benchmark de Magento  ou de tout autre Framework / site, il faut le bon outil et surtout la bonne échelle.

Mesurer c’est une chose, mesurer utile ou interprétable, s’en est une autre. La seule mesure qui compte au final, c’est la satisfaction de l’utilisateur qui surf sur le site concerné.

En l’occurrence une échelle de cette satisfaction existe, l’APDEX.

Le but de cet indice est de mesurer, dans un temps donné, combien d’utilisateurs ont eu un temps de réponse satisfaisant. Dans cette chaine, tout est compté, la charge que le site impose au serveur, le temps d’acheminement des paquets, l’affichage de la page etc.

Autrement dit, si je fixe à 2,5 secondes le temps d’affichage optimal pour un site, combien d’utilisateurs vont pouvoir surfer en même temps sur la machine avant que 1 d’entre eux ait un temps supérieur à 2,5 secondes ? Combien vais-je en accueillir avant que 5% d’entre eux ait une page en plus de 2,5s ?

l’APDEX comprend 4 niveaux :

• satisfied
• tolerating
• frustrated
• inacceptable

c’est donc bien une échelle « user centric ». Le but est de satisfaire l’utilisateur ou tout au moins de ne pas l’irrité. Si l’on fixe la zone de satisfied à moins de 2,5 secondes, la zone de tolérance va de 2,5s, la zone de frustration sera à 10s (4 fois le temps de tolérance) et au delà on est dans l’inacceptable.

Formule de l’APDEX

APDEX = ((nombre de satisfaits) + 0,5*(nombre des tolérants)) / total

(avec le nombre de frustrés = 0)

Si on reprend nos hypothèse et qu’on prend un groupe de 100 tests, mettons que 80 sont sous la barre des 2,5s, 20 sont entre 2,5 et 10 et 0 sont au delà de 10, le coefficient APDEX est de :

(80+20/2)/100=0,9

Se placer sur l’échelle

A 1, tout le monde est satisfait, entre 0,94 et 1, vous êtes dans l’excellence, de 0,85 à 0,94, vous êtes bon, de 0,7 à 0,85 vous êtes honnêtes. de 0,5 à 0,7 c’est mauvais, en dessous de 0,5 c’est la zone de l’inacceptable.

Dans notre exemple au dessus, un APDEX à 0,9 nous donnait 80% d’utilisateurs en zone de satisfaction, 20% en zone de tolérance.

Mesurer cet indice

L’outil Funkload, en dernièreversion utilise cette classification Apdex pour donner des rapports de tests de charge très complet. Une fois que vous avez préparé vos scénarii, il s’occupe de charger la machine jusqu’à ce que l’indice APDEX passe sous une certaine valeur. Une fois cette valeur atteinte, vous avez un nombre d’utilisateur simultanés.

Vous pourrez ainsi facilement mesurer la rapidité de votre site mais en condition réelle. Avec un utilisateur simultané, vous aurez surement des temps de chargements sous la barre de la seconde mais un serveur et son site sont fait pour la vie réelle, pour accueillir des milliers de visiteurs par jour.

Il existe prêt de 30 outils différents à ce jour pour mesurer cet indice mais je vous recommande très fortement Funkload qui permet de faire cela en parallèle d’un test de charge avec des scenarii.

Ordre de grandeur pour Magento

Par exemple, sans Reverse Proxy (RP), avec un serveur de base (bi quadcore 5420 / 8 go), bien configuré et optimisé, sous Magento 1.4 CE, avec un site correct devrait vous amener entre 150 utilisateurs simultanés, tous sous la barre des 2,5 secondes, avec un APDEX à 0,95. (95% des utilisateurs en zone de satisfaction, 5% en zone de tolérance)

Toujours sans RP, un gros molosse (bi hexacore 5670 / 8 Go) devrait vous amener à ~250 utilisateurs sous la barre des 2,5 s avec un APDEX à 0,95. (95% des utilisateurs en zone de satisfaction, 5% en zone de tolérance)

Un mono Quad core AMD 2382 (toujours sans RP), vous amène à 4s pour 150 utilisateurs.

Seulement 100, 150, 200 ? Oui, mais simultanés et sans l’aide d’un rproxy ou du full page cache pour les versions Enterprise de Magento (EE) !

Funkload

Voici quelques captures d’écran de Funkload qui vont vous permettre de mieux comprendre le fonctionnement de l’utilitaire et ce qu’il produit comme rapport :

Sur cette capture, on voit, en haut, le nombre de SPPS (Successfull page per second) et l’échelle du nombre de CU (Concurrent Users), de visiteurs simultanés. Juste en dessous, le graphique suivant montre l’indice Apdex, la barre verte montre un apdex de 0,95 à 20 utilisateurs simultanés (hors cache, hors rproxy etc…)

Ici, le graph montre le nombre de CU et le temps d’attente de chacun. A 40 CU, on a un temps de génération des pages de 2,5 secondes au minimum, 3 pour 90% des visiteurs.

Vous pouvez trouver l’outil Funkload sur le site de son auteur M. Delbosc : http://funkload.nuxeo.org/

Un grand bravo à Nuxeo qui porte haut les couleurs de l’opensource et de la qualité dans ce domaine, une entreprise Française en plus !

Conclusion

Ce que nous cherchons tous à savoir c’est : combien d’utilisateurs puis-je accueillir dans des conditions optimales avec mes serveurs ? La réponse est maintenant à portée de main grâce à un indice représentatif de la qualité de la session de surf : l’APDEX et un outil de mesure et de test de charge : Funkload.

En général, on a deux mesures de ce que peut accueillir un serveur, une mesure en visiteurs uniques par jour et/ou l’autre en visiteurs connectés simultanément. Évidemment, vu le type de mesure Funkload, la deuxième est beaucoup plus réaliste.

Ceci étant, peut de personne peuvent exprimer leur besoin en visiteurs connectés simultanément alors que presque tout le monde sait dire combien il accueille de visites par jour. Du coup, la passerelle entre les deux n’est pas forcément aisée et elle est approximative.Les pics sont bien représenté dans les connexions simultanées mais pas dans un nombre de visiteurs unique par jour.

Disons si on devait donner un ordre d’idée, pour du Magento, le ratio entre les deux serait de 150 utilisateurs simultanés en moins de 2,5s avec un apdex de 0,9 correspond globalement à ~35 000 visiteurs uniques par jour.

Ce coup-ci l’article sera en anglais car c’est une publication d’un white paper rédigé à l’origine par NBS System sur les performances de Magento quand on y couple Zend server. Les tests & benchmarks sont fait entre les versions 1.2, 1.3 et 1.3 avec le flat catalog d’activé puis avec Zend Server et enfin avec Zend server incluant le page cache (version payante).

Ce white paper est en licence Creative commons paternity no commercial use, vous pouvez donc le télécharger, le modifier, le diffuser à votre convenance, sauf pour usage commercial. Celui-ci est uniquement autorisé aux sociétés NBS System, Zend et Varien. (NBS System peut autoriser explicitement l’usage commercial de ce contenu sur demande)

Vous pouvez le télécharger dans sa version PDF intégrale ici.

Magento & Zend Benchmarks

Version 1.2, 1.3 (with & without Flat Catalogs)

1. Foreword

Magento is a PHP/Zend application which intensively uses the CPU. Since version 1.1.6, each new version includes some mechanisms aimed to improve the performances. The goal is to use fewer resources for a given e-shop, which mainly means less CPU, in order to host more users with the same hardware.

One key to achieve better performances is how to optimize PHP pages generation and service. "LAMP" servers are well known and usually run Apache server with mod-php, eventually in fast_cgi mod.

Zend, the PHP Company, made a specific server (Zend Server), which includes a web application stack that (among other things) improves application performances through page caching and opcode reorganization & acceleration.

Apache and Zend Server is an alternative to the usual Apache and mod-php to run Magento, the goal of theses studies & tests is to qualify and estimate the performances added by the use of this software.

Many thanks to Yoav Kutner (Varien's CTO) for providing us with prefilled catalogs for 1.2 and 1.3 version of Magento. Thanks goes as well to Zend labs for providing help in configuration and tweaking of the Zend Server as well as explaining the in depth mechanism of the solution.

2. Methods & tools used

The benchmarks were done using siege (2.66-2), with different numbers of simultaneous threads (5, 10, 20 and 40). Each thread opens a connection to the web server, request a page, and start again as soon as the page is fetched.

Tests were run over 5 minutes each; average pages retrieved was counted for this benchmark.

Two kinds of tests were done: the first one is the simplest; we only load the main page in loop, as fast as possible.

The second test is based on logs produced by a visit, loading all the data the browser collected (including css, js, images ...). As loading a single page would usually load multiple elements, the number displayed is much higher than the number of pages that would be actually seen by visitors.

(18 pages viewed by the user, for 91 items downloaded, a ratio around 5)

All results were obtained on the same hardware and operating system, for testing purposes, no reverse proxy was active during the benchmarks but APC code cache was running. This was a "standard", default environment with no special performance tweaks installed.

Hardware used

Dual Quad-Core AMD Opteron(tm) Processor 2376 (2.3GHz), 8GB Ram, 15K SAS disks. (Dell PE M605)

Software context

Operating system: Linux (2.6.27.10-grsec) on a Debian (lenny)
Web Server: Apache2 (2.2.9-10+lenny2)
PHP (mod-php): mod-php5 (5.2.6.dfsg.1-1+lenny3) / php-apc (3.0.19-2)
PHP (Zend Server): zend-pe (1.0.0-1+b47) / mod-php5-zend-pe (5.2.9+b75)

Repositories

deb http://ftp.fr.debian.org/debian/ lenny main
deb http://security.debian.org/ lenny/updates main
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb http://repos.zend.com/deb/pe pe non-free

3. Magento Versions benchmarks

Those tests were realized on an 80 000 (later called 80 k) products catalog.

Graphs represent the average number of requests successfully loaded from the server per second during the 5 minutes test.

Loading the homepage

Magento 1.3 is much faster than 1.2 showing the main page. Flat Catalogs do not help much displaying this homepage, and seems to even slow down a little under heavy loads. The performance between 1.2 and 1.3 is doubled for low charges and is still 33% higher under heavy load.

For a standard value, under a "standard" load, we can consider that +40% is a reasonable value when running a 1.3 version instead of a 1.2, at least for the homepage.

Full visit cycle

The graph shows a slightly smaller increase with 1.3 compared to 1.2 and the flat catalog mechanism give an overall benefit which greatly increases the performances.

For the records, we can reasonably choose to keep theses values in mind:

Version 1.2 -> 1.3 : +66%
Version 1.3 -> 1.3+Flat Catalog : +20%

4. Apache + mod-php VS Apache + Zend Server

Zend Server (sometimes refered as ZS later on) comes with several built-in technologies for enhancing application performance:

• Zend Optimizer+ performs byte-code optimization and caching. This speeds up PHP applications by eliminating the process of reading scripts from disk and compiling them. Zend Optimizer+ runs automatically, and installing your application on top of Zend Server (ZS) is all you need to do in order to enjoy its benefits. During the test with ZS, APC Code cache is deactivated as Zend optimizer+ is doing the same job.
• Zend Page Cache allows caching of complete PHP pages. Page Caching greatly improves the performance of web applications while maintaining dynamic capabilities through an elaborate system of caching rules that could be based on request parameters and user session data. Page Caching also has the benefit of not requiring any code changes, and can be set up from the Zend Server UI. Only the "pro" version contains this precise piece of software which definitely makes a difference as we will see in a minute.
• Zend Data Cache is a set of API functions enabling a developer to store and manage data items (PHP strings, arrays and other data) and even output elements in either disk-based cache or shared memory cache. Zend Data Cache allows for precision-guided caching when Page Caching is not an option. The provided API is easy-to-use on existing code, and in many cases a developer can skip existing code sections by simply wrapping them with caching APIs. This precise piece of software would benefit from a little remastering of the code by Varien to really achieve a full support of this functionality. If done, we can imagine selectively flushing the cache when changing some pages on the servers and not destroying the whole Magento cache thus doing a "cold cache start" after a new functionality is put online.

Note: Zend Optimizer+ and Zend Data Cache are available in the free, community version of Zend Server, while Zend Page Cache requires a licensed Zend Server (full comparison of Zend Server and Zend Server Community Edition is located at http://www.zend.com/fr/products/server/editions).

Zend Server Configuration for Magento

In the benchmark, two caching rules have been defined:
The first rule caches the JavaScript files which are dynamically merged into one request by Magento.
This simple rule results in a very substantial improvement to response times.

The second rule caches all web pages accessed by users who have nothing in their shopping carts or history (when the shopping cart is not empty or when the user history is saved, there is no point in page caching). As you can see in the screen capture below, this is accomplished by looking at $_SESSION variables and by splitting according to $_SERVER['REQUEST_URI'] in addition to the QUERY_STRING.

Finally, Zend Optimizer+ has been enabled for optimizing and caching the PHP byte-code.

As you can see, Zend Page Cache seems a very powerful feature. It needs fine tuning and better configuration, but let's see results :

Homepage / 80 000 products catalog

Load on main page doesn't prove very constructive, although, on heavy load (40 concurrent requests), Zend Server (with or without page cage) is slightly better than basic mod-php, but almost no real improvements on this test. A 5% or less win is not to be taken seriously as it is the error margin of the tests.

Full visit / 80k products

Full visit graphic speaks for itself, whatever the load, Zend Server with Page Cache and Flat Catalog make a big difference.

Comparing a 1.3 with flat catalog with a the same configuration but with a Zend Community installed instead of just APC, our server yield up to 15% more performances, just using a free edition of ZS.

If we use a full Zend server (the licensed one including the page cache) on this 1.3 flat catalog, our server goes up to 30% more performances!

Mod PHP + APC -> ZS: +15%
Mod PHP + APC -> ZS licensed edition: +30%

5. Response time

Homepage / 80k products

This graph show response time on the homepage measured during a load. No match on this test, under a good load, ZS, community or licensed edition, gives up a 35% boost in the load time, good to take.

Full visit / 80k products

Page Cache provides a better response time over a full visit of the site, even under very heavy load. As the difference remains thin, I would conclude it to be identical in that condition. However, the benefits of the page cache under a standard load remains a must have. Once again, a 35% win is to be considered as a reference value under a good load whether you are using a community or licensed version.

Under medium or light load, the page cache is giving a lot more power than the community edition can do. This strange result is probably mainly due to the page cache mechanism which prove to be not that efficient under heavy load because the system is using its resource in a different way.
We didn't had time to check if it was a False cache sharing effect on L2 or L3 processor cache or a Linux or ZS issue but the test has been runned several times yielding the same results.

So keep in mind that the benefits of the ZS Page cache mechanism is going to be less and less active as the server load gets high. Under a usual load, a reasonable load lets say, the Page Cache algorithm gives a nice boost to the loading time, driving it down for ~40%.

6. Additional technical details about the tests

Sample data

All tests were run with generated sample data (provided by Varien)

Description of the tests

Main page test

Each concurrent thread loads the main page, without storing the cookies to simulate simultaneous users.

Full visit test

We have a list requests based on a visit done with a real browser. Each concurrent thread loads each item one after another as fast as possible, and restarts after deleting all its cookies. This simulates simultaneous users, except that simultaneous.

List of requested pages for the 80k database (with POST information when it applies):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

<span style="font-size: xx-small;">http://test80k/
http://test80k/skin/frontend/default/default/favicon.ico</span>
<span style="font-size: xx-small;">http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js
http://test80k/skin/frontend/default/default/css/reset.css
http://test80k/skin/frontend/default/default/css/menu.css
http://test80k/skin/frontend/default/default/css/print.css
http://test80k/skin/frontend/default/default/css/clears.css
http://test80k/skin/frontend/default/default/css/boxes.css
http://test80k/skin/frontend/default/default/images/body_bg.gif
http://test80k/skin/frontend/default/default/images/logo.gif
http://test80k/skin/frontend/default/default/images/btn_mini_search.gif
http://test80k/skin/frontend/default/default/images/mini_search_bg.gif
http://test80k/skin/frontend/default/default/images/nav_bg.jpg
http://test80k/skin/frontend/default/default/images/nav_divider.gif
http://test80k/skin/frontend/default/default/images/main_container_bg.gif
http://test80k/skin/frontend/default/default/images/shop_access_pipe.gif
http://test80k/skin/frontend/default/default/images/base_mini_head_bg.gif
http://test80k/skin/frontend/default/default/images/media/col_left_callout.jpg
http://test80k/skin/frontend/default/default/images/header_top_container_bg.jpg
http://test80k/skin/frontend/default/default/images/icon_table.gif
http://test80k/skin/frontend/default/default/images/icon_newspaper.gif
http://test80k/skin/frontend/default/default/images/icon_tag_green.gif
http://test80k/skin/frontend/default/default/images/icon_basket.gif
http://test80k/skin/frontend/default/default/images/media/col_right_callout.jpg
http://test80k/skin/frontend/default/default/images/footer_info_separator.gif
http://test80k/skin/frontend/default/default/images/main_bg.gif
http://test80k/category-736
http://test80k/skin/frontend/default/default/images/layered_nav_head_bg.gif
http://test80k/skin/frontend/default/default/images/layered_nav_narrowed_category_heading.gif
http://test80k/skin/frontend/default/default/images/narrow_by_set.gif
http://test80k/skin/frontend/default/default/images/narrow_by_dd_bg.gif
http://test80k/skin/frontend/default/default/images/pager_arrow_right.gif
http://test80k/skin/frontend/default/default/images/sort_asc_arrow.gif
http://test80k/media/catalog/product/cache/1small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/skin/frontend/default/default/images/pager_bg.gif
http://test80k/category-736?attribute_864=306
http://test80k/skin/frontend/default/default/images/list_remove_btn.gif
http://test80k/skin/frontend/default/default/images/narrow_category_bg.gif
http://test80k/skin/frontend/default/default/images/narrow_by_li_by.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=2
http://test80k/skin/frontend/default/default/images/pager_arrow_left.gif
http://test80k/category-736?attribute_864=306&amp;price=3%2C100&amp;p=3
http://test80k/category-736/gtx14049.html
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/product.js,calendar/calendar.js,calendar/lang/calendar-en.js,calendar/calendar-setup.js
http://test80k/js/calendar/calendar-win2k-1.css
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/skin/frontend/default/default/images/product_essential_bg.gif
http://test80k/skin/frontend/default/default/images/product_collateral_bg.gif
http://test80k/skin/frontend/default/default/images/dotted_divider.gif
http://test80k/skin/frontend/default/default/images/icon_tag_add.gif
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS03MzYvZ3R4MTQwNDkuaHRtbD9fX19TSUQ9VQ,,/product/67952/ POST product=67952&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/js/index.php?c=auto&amp;f=,prototype/prototype.js,prototype/validation.js,scriptaculous/builder.js,scriptaculous/effects.js,scriptaculous/dragdrop.js,scriptaculous/controls.js,scriptaculous/slider.js,varien/js.js,varien/form.js,varien/menu.js,mage/translate.js,mage/cookies.js,varien/weee.js
http://test80k/skin/frontend/default/default/images/btn_proceed_to_checkout.gif
http://test80k/skin/frontend/default/default/images/btn_trash.gif
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/skin/frontend/default/default/images/success_msg_icon.gif
http://test80k/skin/frontend/default/default/images/icon_asterick.gif
http://test80k/skin/frontend/default/default/images/icon_lorry.gif
http://test80k/skin/frontend/default/default/images/data_table_th_bg.gif
http://test80k/skin/frontend/default/default/images/base_mini_actions_bg.gif
http://test80k/category-736/gtx14049.html
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-1497
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/category-1497?attribute_864=305
http://test80k/category-1497/npt25-a.html
http://test80k/media/catalog/product/cache/1/image/265x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/image.jpg
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0xNDk3L25wdDI1LWEuaHRtbD9fX19TSUQ9VQ,,/product/25870/ POST product=25870&amp;related_product=&amp;qty=
http://test80k/checkout/cart/
http://test80k/media/catalog/product/cache/1/thumbnail/75x/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg
http://test80k/category-3?price=4%2C1000
http://test80k/checkout/cart/add/uenc/aHR0cDovL3Rlc3RtMTIudGVzdC5uYnMtc3lzdGVtLmNvbS9jYXRlZ29yeS0zP3ByaWNlPTQlMkMxMDAwJmNhdD0zNyZfX19TSUQ9VQ,,/product/4642/
http://test80k/checkout/cart/
http://test80k/checkout/onepage/
http://test80k/js/varien/accordion.js
http://test80k/skin/frontend/default/default/js/opcheckout.js
http://test80k/skin/frontend/default/default/images/opc_off_head_bg.gif
http://test80k/skin/frontend/default/default/images/opc-ajax-loader.gif
http://test80k/skin/frontend/default/default/images/btn_window_close.gif
http://test80k/skin/frontend/default/default/images/cvv.gif
http://test80k/skin/frontend/default/default/images/multi_address_box_bg.gif
http://test80k/skin/frontend/default/default/images/btn_place_order.gif
http://test80k/catalogsearch/ajax/suggest/ POST q=45
http://test80k/catalogsearch/ajax/suggest/ POST q=456
http://test80k/catalogsearch/result/?q=456&amp;x=17&amp;y=8
http://test80k/media/catalog/product/cache/1/small_image/135x135/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/small_image.jpg
http://test80k/media/catalog/product/cache/1/thumbnail/50x50/5e06319eda06f020e43594a9c230972d/images/catalog/product/placeholder/thumbnail.jpg</span>

7. Things to test in the next benchmark campaign

Mage Compiler

When running all those tests, 1.3.1.1 version including the Mage optimizer was about to be released and an immediate 1.3.1.2 version followed and we didn't had time to include some tests around this precise point. Let's just consider the fact that this mechanism is mainly made to lower I/O jobs by "compiling" the libraries files all in one or two includes only. If your servers were already using mainly their RAM to work, the performances increase will not be that valuable. But if your servers where low on RAM or using mainly their disks, you should feel confident with using this option which can do great good to your performances!

Nginx

We didn't had the required time to consolidate the results involving Nginx + PHP tests. This solution ranked almost every time between Magento 1.3 + FC and Magento 1.3 + Zend server (without Page cache). So this combination yield average performances, not as sharp as a Magento 1.3 + Zend server or any more advanced combination.

More "customed" visits

We have used a scenario involving each time a research in the search bar of the website and some "standard" behaviors. A more precise test can be run replaying some real traffic pumped up from apache log on a real site, the customer's behaviors being more realistic even if our scenario was as logical as possible.

8. Conclusion

First, let me say that no electrons were armed or injured during these benchmarks. Perhaps one or two CTO were put under constraint and continuous coffee perfusions but all of this was intend for the greater good of E-commerce!

If you wish a more professional conclusion, let's say that using ZS community edition will only do you good and really can replace APC.

If using the licensed version, the Page cache is very efficient (under reasonable load of the servers) and can help using ~25% less machines to achieve similar hosting capacities. If your servers are billed in a "managed hosting" way, having one or two less servers billed per month can make a good difference in the budget.

About Zend Server : this software has many other great functionalities and this paper is only consider the "performances" issues, just pay a visit to Zend Website for a far more complete overview of the product.

Last but not least, creating a server with all optimizations and best practices, based on an a dual AMD 2376 with 8 Go of RAM and using ZS and page cache, you can try to reach up to ~40 000 unique visitors a day corresponding to ~2 500 Magento simultaneous session at maximum load. (if database is separated on a different server and you activate a reverse proxy like Squid or Varnish above your front web servers)
This estimation is deeply linked to the website complexity and user standard behavior but these figures are given for a "standard" site and use, you can usually also expect a ~2 seconds loading time on the homepage.

If we had to sum up a quick dirty, average table of the performances, without any details, we would give that:

© June 2009, NBS Team,

René Amirkhanian, Adrien Urban, Philippe Humeau,
you can visit us here: www.nbs-system.com
and reach us at: contact@nbs-system.com for any comments or corrections (and yes, we do hosting )

9. Creative Commons

This document is released under the creative common license "Attribution-Noncommercial-Share Alike 3.0". Only three companies (NBS System, Zend and Varien) are allowed to use it for commercial purposes.

Alors, où en est-on sur le front des performances ?

Eh bien si vous avez mis en place les optimisations qui sont recommandées, celles que l’ont vous a expliqué chez Fragento ou ici, celles que l’on va vous exposer dans les prochains posts, bref si vous faites les choses correctement, vous pouvez atteindre de 200 à 800 sessions « Magento connectées » par core (coeur) de vos processeurs récents.

Mais avant de parler des optimisations en elles mêmes, il faut avoir des moyens de comparer, des unités et des repères communs. Je vous propose d’adopter des « S.M.C » comme unité.

S.M.C ?

En premier lieu « Sessions Magento Connectées », qu’est-ce que cela peut bien représenter… ?

Déjà, on va réduire le nom à SMC pour éviter de trimbaler 5 lignes. On peut prendre de nombreux points de repères différents pour estimer la charge : les sessions apache, les Visiteurs Uniques (V.U) journaliers, horaires, le nombre de page vues, etc… Alors pourquoi choisir les SMC ?

Les SMC cela reste un indicateur pertinent car c’est Magento qui mesure cette valeur. Elle peut donc être utilisées dans d’autres contexte, pour faire d’autres calculs mais surtout elle est mesurée partout de la même façon, ce qui est important pour avoir des repères. Comme c’est Magento qui la mesure, on travail tous sur la même valeur.

Comment les récupérer ? Avec une requête SQL en base de données tout simplement :
select count(*) from log_visitor where ADDTIME(utc_timestamp(), -1500) < last_visit_at;

Cela nous donne les sessions ayant eu une activité lors des 15 dernières minutes. C’est très proche de ce que l’on a dans le backoffice. Une dataquery et un script bash plus tard,

On en fait un beau graphique pour les clients dans Cacti ou avec RRD, MRTG etc… :

Là, par exemple, on voit un mailing. Monté en charge progressive du nombre de SMC pour atteindre les 1200 vers 18H00. Ca se corrèle bien avec le graphique d’utilisation des cores :

On 4 cores utilisés pour 1200, donc 300 utilisateurs par core, en l’occurence ce sont des AMD Shanghai 2374 à 2,3 Ghz. Comme ce sont des quad cores, on utilise un processeur complet. Évidemment on ne peut pas se permettre d’avoir tous les cores à 100% donc les autres processus Linux tournent sur un autre core dédié d’un autre processeur. Coté base de données, ca glandouille gentillement :

Il faut lire 0,2 core (200 milli). Ceci étant ce site spécifique sollicite peu la base de données donc ce n'est pas représentatif non plus.

Tester les performances, tests de charge & Benchmark !

De nombreux outils existent, qui mesurent différentes choses. En test de charge purs, on a par exemple Load runner, Apache bench, Opensta etc… Coupler tout cela à des analyseurs de code ou de requêtes SQL (comme la console Mysql enterprise par exemple) permet d’optimiser le code mais ce n’est pas le sujet de ce post et Gilles nous fera peut être un petit article là dessus.

Non, ce qui nous intéresse ici, c’est d’évaluer le nombre de SMC que l’on peut servir dans de bonnes conditions avec la plateforme que l’on aura préparé. Pour cela, load runner et Opensta sont de bons outils. Apache bench n’est pas très adapté sincèrement car son test est toujours le même, donc avec la chaine de cache, à la fin de ces 2000 itérations, il vous sort joyeusement 250 000 connectés

Opensta permet de définir des scénarii de tests et d’en jouer plusieurs, de front, à suivre, plusieurs fois les mêmes etc… Le soft tourne sous Windows, il est gratuit et opensource. On peut le trouver ici et même s’il n’est plus entretenu, il fonctionne bien et fait le boulot demandé.

Le but ici n’est pas de faire un manuel ou un howto d’opensta mais globalement d’expliquer ce qui représente de bonnes circonstance de tests, tout au moins réaliste. Ce que je fais, en général, c’est que je demande à mes clients, c’est de réaliser entre vingt et trente scénarii classique de surf. On enregistre un très simple de la personne qui vient sur la home et se déconnecte, un autre ou il fait une recherche un autre ou il clique de produit en produit, etc… Le plus le mieux mais également, le plus logique le mieux !

Le scénario de connexion à la home puis déconnexion, on va le jouer 25% du temps, puis celui du parcours de produit 1, le 2 et aussi les recherches. On mixe le tout savamment et on demande à plusieurs scénarii de se jouer sur le site. Trois qui surf, des connexions déconnexions sur la home, deux recherches en même temps etc… A la fin, on regarde les performances affichées par l’interface d’Opensta et celles collectées dans Cacti. On corrèle les graphs, on analyse et on arrive à estimer la charge que peux tenir un système ! En laissant tourner les scénarii un moment, le graph sera réaliste et on saura dire combien de S.M.C peut faire tenir un core standard.

La suite est un jeu d’enfant, on prend le nombre de V.U prévu en pic, on déduit le nombre de S.M.C que l’on doit pouvoir encaisser et on divise par la performance unitaire d’un Core. On sait alors combien de core on doit mettre en place et donc combien de processeurs !

Bon si une bonne âme veut bien écrire un tuto/howto sur Opensta, je passe mon tour pour le moment et je vous laisse juste en compagnie de deux shoots d’écran, le modeler et le commander :

On définit son scénario dans le modeler ci-dessous, on planifie dans le commander ci-dessus, et on a un autre module qui collecte et affiche les statistiques.

Et voila !