Etape 1 : Identification du scénario fonctionnel
La première étape consiste toujours à identifier son scénario.
Pour ce test, j’ai déployé une petite application sur un serveur Tomcat, cette application va interroger une base de données MySQL pour avoir une liste de boxeurs (environ 400 éléments). L’application va le faire de 4 façons différentes :
- Accès direct à la base de données via JDBC (pour chaque appel : ouverture connexion, requête SQL, fermeture connexion)
- Accès direct à la base de données via JDBC mais avec les étapes d’ouverture et de fermeture de connexions dans le init() de la servlet (donc pour chaque appel, on réutilise la même connexion)
- Accès à la base de données via un pool de connexions géré par Tomcat, récupéré par JNDI
- Accès à la base de données via un pool de connexions géré par Tomcat avec en plus une vérification de la validité des connexions avant / après les avoir prises ou rendues.
Dans tous les cas, c’est la même liste qui est affichée.
Ecran 1 : choix du type d’accès
Ecran 2 : début de la liste de boxeurs
Ecran 3 : fin de la liste de boxeurs
Etape 2 : Préparer son scénario de « paliers »
Il faut « modéliser » son scénario de tir de charges en palier, ceci afin de le produire dans JMeter, c’est à dire paramétrer et configurer JMeter pour qu’il reproduise les paliers voulus.
Pour notre cas, nous allons avoir le scénario de paliers suivants :
| Temps (secondes) | Nombre de threads |
| T+0 | 0 VU |
| T+0 à T+500 | Montée de 0 à 50 V |
| T+500 à T+1000 | Palier à 50 VU |
| T+1000 à T+1500 | Montée de 50 à 100 VU |
| T+1500 à T+2000 | Palier à 100 VU |
| T+2000 | Descente à 50 VU |
| T+2000 à T+2500 | Palier à 50 VU |
| T+2500 | 0 VU |
Exprimé dans un graphique, cela donne :
Ensuite passons à l’étape suivante.