Nous allons définir ce qu’est un test de montée en charge de manière générale, dans le contexte d’une architecture Web. En effet, le principe de test est différent selon le type d’architecture (protocole d’échange différent, comportement d’architecture différent, etc.).

1. La simulation d’une charge

Un test de montée en charge consiste à solliciter une architecture, un site ou une application web. L’objectif est de simuler un nombre important d’utilisateurs, par l’intermédiaire d’outils spécialisés réalisant des requêtes HTTP, dans le but final d’analyser le comportement de l’architecture à l’aide notamment d’outils de monitoring. Une plate-forme de simulation disposant d’outils de test de montée en charge permet de simuler ces utilisateurs que l’on appelle également automates ou robots.

Simulation d’une charge sur l’architecture

Lors de la simulation d’un grand nombre d’utilisateurs, l’introduction simultanée de ces derniers peut provoquer des dysfonctionnements du fait que l’architecture reçoit d’un seul coup un nombre beaucoup trop important de requêtes alors qu’aucune activité n’était en cours. C’est pourquoi il est préférable, à partir de la simulation de 10 utilisateurs, de faire démarrer les automates de manière progressive (5 automates toutes les 10 secondes par exemple) pendant une phase dite de préparation. La phase de mesure des performances peut avoir lieu seulement lorsque le nombre d’utilisateurs voulu est en activité.

Exemples de simulations de 100 utilisateurs

En effet, si une forte charge est émise directement, l’architecture risque de ne pas la supporter et de nombreuses erreurs seront retournées.

2. La montée en charge

Le concept de montée en charge consiste à qualifier l’architecture testée dans sa capacité à pouvoir supporter un nombre d’utilisateurs croissant sans défaillir. Il est envisageable de réaliser une montée en charge de manière continue ou par séries. La principale différence entre les deux approches réside dans le fait que dans un cas le test est réalisé d’une seule traite alors que dans l’autre cas, le test est fractionné en plusieurs prises de mesures successives.

Différents types de montées en charge

Il est intéressant de mettre en place une montée en charge continue dans le cadre de tests sur la durée afin de tester le comportement de l’architecture sur un temps d’exercice plus long. Cette façon de procéder est plus complexe à mettre en œuvre et plus risquée.

En effet, cela signifie que le test est complètement automatisé et la collecte des informations est réalisée au fur et à mesure, en même temps que le monitoring. Par ailleurs, il est beaucoup plus complexe de connaître l’impact du nombre d’utilisateurs simulés. De plus, ce genre de test est assez long et si un problème est rencontré pendant la simulation, il faut alors recommencer à nouveau toute la montée en charge.

Il est plutôt conseillé de mettre en œuvre une montée en charge par série afin de pouvoir plus simplement analyser les résultats et rejouer une session de test indépendamment des autres en cas de problème. Mais surtout, cette stratégie permet de remettre dans un état identique l’architecture (volume de données en base identique, taille mémoire initiale identique, nombre de sessions ouvertes identique, etc.) pour chaque série de mesure et ainsi pouvoir correctement mesurer l’impact du nombre d’utilisateurs en comparant chacune des mesures.

Par exemple, si le test réalisé correspond à la création de contrats et qu’une des étapes du scénario doit exécuter une recherche (qui n’est pas optimisée) parmi l’ensemble des contrats alors le temps de réponse sera de plus en plus long pour cette page au cours du test. Ainsi, si les conditions de test ne sont pas identiques pour chaque session de mesure, l’analyse de la montée en charge est biaisée car les résultats observés ne seront pas dus à l’augmentation de la charge mais au composant de recherche qui pose problème. Il faut mettre en place un test d’endurance (avec un nombre constant d’utilisateurs) pour observer ce genre de comportement et démontrer que le problème provient du module de recherche.

Graphe comparatif avec et sans remise à zéro entre chaque mesure

Par ailleurs, lors de la mise en place de ces tests, il est envisageable de réaliser une série de mesures dans un temps imparti ou selon un nombre d’itérations défini du scénario de test. Il est fortement conseillé de fixer un nombre d’itérations afin de maîtriser parfaitement le nombre de pages générées et le nombre de transactions réalisées, et ainsi pouvoir valider la fiabilité de l’architecture selon des règles de calcul bien définies. Ainsi, il est préférable de choisir pour chaque série de mesures le nombre d’itérations à réaliser par chaque automate :

Définition d’une montée en charge
Nombre d’automates	1	5	10	20	50	100	200
Nombre d’itérations	200	200	100	50	20	10	10

3. Charge constante (test d’endurance)

La mise en œuvre d’une charge constante consiste à simuler un même nombre d’utilisateurs pendant toute la durée du test. Ce genre de simulation est souvent utilisé lors de tests d’endurance en augmentant le nombre d’itérations (par exemple, 10 utilisateurs réalisent 2000 itérations). Même s’il est envisageable de mettre en place un test d’endurance en augmentant le nombre des automates simulés, il est préférable de le conserver constant afin de pouvoir bien apprécier le comportement de l’architecture dans la durée indépendamment de l’augmentation de la charge.

L’objectif principal de cette façon de procéder est de déterminer l’impact d’une utilisation longue de l’application sur les performances, mais aussi sur les ressources physiques. En effet, il est possible de démontrer l’existence d’une fuite mémoire en réalisant un test plus long alors que le phénomène aurait pu être raté lors de la montée en charge.

Comportement des ressources en cas ou non de fuite mémoire

Cependant, il est intéressant de réaliser un test à charge constante après des tests de montée en charge afin de déterminer quelle est la charge la plus représentative et résoudre les éventuels problèmes. En effet, cela évite d’avoir à rejouer plusieurs fois le scénario de test qui est souvent long.

Pour plus d’informations sur le sujet, n’hésitez pas à télécharger le livre blanc Osaxis « L’étude des performances : méthodologie et outils de tests de montée en charge Web ».