Le test de charge a pour objectif d’avoir une idée de l’audience que pourra supporter le site testé. Sauf que le test est généralement fait sur une durée relativement courte avec des scénarios plus ou moins réalistes. A partir de là, on va essayer d’extrapoler l’audience produite par le test en un nombre de visites par mois, par jour, en nombre de sessions simultanées et en nombre de conversions à l’heure quand il s’agit de boutiques en ligne.
On va s’intéresser à l’audience d’un site de commerce en ligne. Avant de passer une commande sur un site de commerce en ligne, un internaute va peut-être passer 20 minutes à naviguer sur le site pour parcourir le catalogue et remplir son panier. Ensuite, il va passer la commande, créer son compte, saisir son adresse de livraison, effectuer le paiement, et éventuellement vérifier sa commande sur le site. Il aura passé 30 minutes sur le site.
Afin de simuler l’audience, nous utilisons l’outil JMeter (https://jmeter.apache.org).
Si on veut simuler une audience équivalente à 600 commandes à l’heure, il faudra lancer notre scénario 600 fois en une heure. Comme il dure 30 minutes, il faudra lancer 300 threads en parallèle qui vont chacun effectuer 2 scénarios. On aura bien nos 600 commandes en une heure, sauf qu’on imagine que les passages de commande vont se trouver plutôt à la fin des 30 minutes, on aura donc un biais par rapport à la réalité.
Si on veut supprimer ce biais, il faudrait que l’injecteur soit dans un rythme de croisière nominal, avant la prise des mesures, afin que les aléas temporels du scénario permettent de distribuer les commandes. Ca veut dire, qu’il faudra lancer les 300 threads quelques heures auparavant et au moins 30 minutes après l’heure de mesure.
Et si le site de commerce en ligne à un taux de conversion de 5%, c’est à dire le nombre de visiteurs qui vont passer une commande, il faut multiplier par 20 le nombre de scénarios exécutés par l’injecteur, sachant que 95% pourcents d’entre eux ne doivent pas passer de commande. En conservant des scénarios de 30 minutes, il faudra 6000 threads pour simuler l’audience et faire durer le test un bon paquet d’heures….
Bref, dans ces conditions, la simulation de la réalité devient très difficile en pratique, car la durée des tests est prohibitive !
Afin de permettre la réalisation des tests dans des durées acceptables, on va raccourcir la durée du parcours d’un visiteur.
On va faire la supposition que lancer 300 threads qui jouent un scénario de 30 minutes pendant 1 heure, c’est équivalent pour le site qui reçoit les visites à 30 threads qui jouent un scénario de 3 minutes pendant 1 heure.
Dans les 2 cas, on aura exécuté 600 scénarios en 1 heure. Le site aura répondu aux mêmes sollicitations sauf que dans le deuxième cas, le rythme de croisière sera atteint dix fois plus rapidement, facilitant du même coup la réalisation du test qui pourra durer 10 fois moins longtemps !
Si finalement, le scénario est accéléré pour durer 30 secondes, avec un enchaînement de 20 à 40 requêtes HTTP et des aléas temporels de quelques centaines de millisecondes entre les requêtes, on obtient l’équivalent de la charge précédente avec 5 threads pendant 30 secondes.
Si on fait durer ce dernier test 10 minutes, chaque thread aura fait 20 boucles. On n’est pas loin d’un rythme de croisière avec suffisamment d’aléa pour le considérer comme représentatif d’une audience de 600 commandes à l’heure.
Une manière simple de créer des tirs sur JMeter simulant une charge données est d’utiliser les paramètres “Number of Threads” et “Ramp-up period” dans l’objet “Thread Group”
Dans l’exemple ci dessous :
les 30 threads seront atteint après une période de 20 minutes, pendant laquelle, JMeter va graduellement augmenter le nombre de threads pour passer de 1 à 30, puis il va continuer avec ce nombre de threads pendant 10 minutes, jusqu’à l’arrêt du test.
Le graphique du nombre de threads en fonction du temps est le suivant :
On peut remarquer que si la durée du “Ramp-up” fait les ⅔ de la durée totale, alors les surfaces A et B ci-dessous sont égales :
Si le nombre de conversion réalisées par JMeter pendant toute la durée du tir vaut N, alors, le nombre de conversions effectuées pendant la période nominale, ici, les 10 dernières minutes, vaut la moitié, soit N/2.
On peut dire que le nombre de conversions à l’heure vaut N/2×6, soit 3N conversions à l’heure.
Si les statistiques de la boutique indiquent un taux de conversion de 5%, alors, en ajoutant des scénarios sans conversion et en multipliant le nombre de threads par 20, on simulerait l’audience de la boutique.
Pour calculer l’audience équivalente au tir ci-dessus, on peut dire qu’on a 3Nx20 visiteurs à l’heure. Comme une session dans les usages du Web est comptabilisée après 30 minutes d’inactivité, on peut dire qu’on a un équivalent de 2x3Nx20 sessions simultanées.
Comment estimer le trafic quotidien et mensuel ?
La réponse dépend largement du type du site et des habitudes de fréquentation.
On peut se lancer dans un calcul à la louche, sachant qu’on obtient des ordres de grandeur et qu’il faut adapter le calcul en fonction des statistiques du site.
Si on estime que l’heure du pic d’affluence représente 20% du trafic de la journée, dans notre cas 3Nx20 visiteurs, pour la journée on en aurait 5 fois plus, soit Nx300 visites par jour.
Reste à extrapoler au mois. Si on considère que le jour le plus chargé représente 10% des visites du mois, on aurait Nx3000 visites par mois !
Si N vaut 100, notre tir produirait une charge équivalente à :
- 300 commandes à l’heure,
- 30 000 visites par jour,
- 300 000 visites par mois.