Benchmark ECOM 2015 GRP5
Evaluation système
Introduction
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1.
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.
Description du système :
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur. L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.
La VM est hebergée derrière une Box orange, avec les propriétés suivantes :
- Bande passante :
- Mentente : 400 Mégabytes (en théorie)
- Descendante : 800 Mégabytes
Capacité alloué a la machine virtuelle :
- RAM allouée : 2 Go
- HDD alloué : 20 Go
- CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)
Objectif :
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application. D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : La VM se trouvant derrière une Box Orange, il est très possible que le débit montant soit plus limitant que le débit théorique de l’abonnement (400 Mégabytes théorique) La Box Orange n’est pas concu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant. L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. Leur utilisations se fait sentir notamment
Scénarios :
Plan 1 :
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communent à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant :
- Visiter la page du site
- Visiter 2 formules
- Ajouter les 2 formules au panier
- Authentification et passage de la commande.
Propriétés de simulations :
- Durée de la simulation : 15 min
- Nombre de thread total (user) : 205
- Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.
- Nombre d’itération : infini
- Nombre de requête par seconde (RPS) : 1
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.
Identification du point de rupture :
