Communauté Magento francophone

Test de charge de son serveur de E-commerce

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.

écrit par Philippe Humeau \\ tags: apdex, benchmark, funkload, magento, test de charge

Avant toute chose, le Wiki a été mis à jour sur la partie dimensionnement des infrastructures Web. Ca se passe ici, si vous voyez des erreurs, n’hésitez pas à corriger.

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 !

écrit par Philippe Humeau \\ tags: benchmark, performance, sessions magento, test