création d’un test en charge

Pour faire un bon test en charge il y a quelques étapes à respecter : que font vos utilisateur, trouver le bon mix , etc..

Peut-on créé un test en charge parfait ?

C’est la question que se pose tout le monde, voir le résultat que tous le monde attend, et pourtant cela n’existe pas ! Un test en charge parfait n’est tout simplement pas possible, en effet vos utilisateurs changent tout le temps, vous ne pourrez jamais avoir l’intégralité des transactions. De plus, cela coute de l’argent contrairement à un capacity planning. Dans le contexte d’un test en charge un résultat “suffisant” est ce que l’on va chercher.

Notre test est-il valide ?

La validation de notre test est une étape importante une fois que l’on a définit et créé celui-ci. C’est cette étape qui va permettre de voir si les résultats sont cohérent et représentatif. Pour ce faire, le plus simple est de faire un test en utilisant une charge correspondant à un jour normal et moyen. Puis de comparer les indicateurs de performance avec ceux de la réalité.

Si votre test simule correctement la réalité de la charge alors serveurs doivent avoir une charge similaire.

Prenons, un exemple. Si à votre heure de référence, les transactions sont de 50 TPS et que la charge de votre serveur critique est de 20%, alors vous devez retrouver des valeurs proches lors de votre test de validation.

Il faut toutefois faire attention à la notion de “proche”. Pourquoi ? Imaginons que ce que vous cherchez à vérifier est un pic à 4 fois votre charge habituelle. Une petite différence sera 4 fois plus importante dans votre test. Encore une fois prenons un exemple :

Supposons que nous comparons 2 indicateurs :

charge réel notre test
mesure 1 20 % 19 %
mesure 2 30 % 20 %

Si on ne regarde que la mesure 1, on se dit “super” notre test est valide, pourtant si on regarde la deuxième, et que l’on applique la règle de base du capacity planning, on va se rendre compte que notre test n’est pas représentatif car 30 * 4 = 120 et il y a surcharge alors que pour notre test 20 * 4 = 80 et on aurait encore de la marge. Cela montre qu’il est importante de valider et comparer sur plusieurs indicateurs si possible les plus pertinent pour notre usages et prêter attention aux petits écarts.

Que doit comporter notre test ?

Il est rare que notre application soit simple, elle est beaucoup plus souvent complexe, comportent de nombreuse transactions et de nombreux serveurs. Pourtant, toutes ne sont pas égale. De façons générale on constate que les revenues ne viennent que de quelques unes d’entres-elles. De même, un nombre important de transaction différentes d’un point de vues utilisateurs sont semblable en terme de ressources.

Fort de ces constatations, on peut bâtir la liste des transactions en prenant celles qui constituent le noyau de votre charge, plus toutes celle qui apporte de l’argent à la société. Il est aussi utile d’ajouter toute transactions qui a récemment causé des soucis en production ou qui sont sensible politiquement. Une fois cette liste établie, il est bon de la parcourir et de regroupé toute les transactions dont le cout en calcul est similaire. l’objectif est d’obtenir une liste relativement courte.

Scripting

Une fois les transactions recensées, il va falloir les scripter. C’est le plus gros du travail car chaque utilisateur est différent (ex: pause), il y a des contraintes (ex: legal) qui vont vous complexifier la tache car par exemple, un user ne pourra que se loguer une fois, ou il aura une limite de panier voir de paiement, etc. Et toutes ces contraintes vont devoir se retrouver dans votre scénario. La manière la plus simple d’y arriver est de travailler par étapes :

  • on écrit le scénario de base
  • on ajoute la variabilisation (utilisateur différent, gestion de panier, etc. )
  • ajouter les tests pour réagir aux réponses de l’application, ex: vérifier que l’article a bien été ajouter au panier, ou article plus en stock, que la page est bien complète, si il y a un login que le nom est le bon, si vous avez fait une recherche, que le résultat est celui attendu, les codes de retour serveur , etc.
  • si votre transaction est en plusieurs étapes, chacune d’elle devra être tester bien évidement. Si l’une d’elle échoue il faudra bien évidement arrêter la transaction.
  • Dans l’idéal, il faut faire cela transaction par transaction, et chaque transaction devra être tester individuellement. Une fois toutes les transactions scripté, l’étape suivante consiste à les exécuté simultanément. Bien sur, dans un premier temps, cette exécution se fera uniquement avec une faible charge, toujours dans l’idée de validé le fonctionnement et de s’assuré que tous va bien.

    La dernière étape sera la fameuse validation ou notre test devra être comparable à ce que l’on observe.

    Une fois tout cela réalisé, nous aurons tous les éléments pour enfin lancer notre test en charge. Quand je vous disait que c’est couteux et consommateur comparativement à un capacity planning !

    Leave a Reply

    You must be logged in to post a comment.