Les tests de performance, planifiés en tenant compte de la capacité de l’environnement de production, devraient idéalement être effectués bien avant la date de mise en service. Elle doit être réalisée dans un environnement de production afin d’identifier le maximum de problèmes de performance lors de la phase de test. Mais maintenir une réplique de l’environnement de production est coûteux et la plupart des entreprises essaient d’éviter ces dépenses en passant à un environnement de faible capacité. Le résultat final est un environnement de test de performance réduit. Il en résulte des lacunes béantes dans le système.
2 + 2 = 5
Oui, c’est exactement comme cela que les choses se passent dans les tests de performance. Chaque test (et donc les facteurs qui y sont associés) est régi par un certain nombre de paramètres et on ne peut pas se contenter de réduire de moitié (ou d’un autre pourcentage) les besoins en CPU et en mémoire de l’environnement et de le tester avec la moitié (ou un autre pourcentage) du nombre d’utilisateurs. Il faut être très prudent avec cette approche, car la plupart des équipes de développement d’applications ont tendance à adopter cette approche et à commettre des erreurs. La performance d’une transaction commerciale, comme je l’ai dit, dépend de nombreux facteurs tels que l’unité centrale, la mémoire, le type d’équilibrage de la charge, la latence géographique, etc. En réduisant le nombre d’utilisateurs dans le test, nous avons tendance à commettre des erreurs telles que –
- Chaque utilisateur connecté à une application à partir d’un client consomme des ressources sur les serveurs d’application, de base de données et web. L’état de session associé à la connexion de l’utilisateur en est le meilleur exemple. Les informations relatives à l’état de la session sont stockées dans la mémoire du serveur et y restent jusqu’à ce que l’utilisateur soit connecté au système. Ce n’est que lorsqu’il se déconnecte que sa session expire et que ses données sont effacées. Dans de nombreuses applications, cela représente une consommation importante de mémoire sur les serveurs. Si un nombre réduit d’utilisateurs est utilisé dans la PT, moins de problèmes de session/mémoire sont identifiés. Il est possible que l’équipe de développement n’ait pas connaissance de ces problèmes de mémoire lors des tests et que les clients y soient confrontés.
- En outre, en sous-estimant le nombre d’utilisateurs, on fait un compromis sur le nombre de connexions simultanées entre les clients et les serveurs. Les paramètres de l’application ou du serveur web peuvent avoir des limites de connexion et les problèmes liés au dépassement de ces limites ne sont pas révélés pendant les tests. En outre, chaque demande simultanée peut nécessiter une connexion à la base de données et le serveur de base de données peut limiter le nombre de connexions simultanées. Idéalement, une base de données devrait être capable de traiter le nombre de lectures et d’écritures simultanées pendant l’exécution et cette simultanéité est la cause principale de nombreuses défaillances liées à la charge.
Ainsi, lorsque l’environnement est divisé par deux, sa capacité n’est pas divisée par deux et vous ne pouvez donc pas tester l’environnement avec la capacité divisée par deux, car les résultats concernant le temps de réponse ne seront pas fiables.
Blocs morts et blocs vivants
Les blocages de base de données se produisent dans un système lorsque plusieurs processus attendent que l’autre (les autres) libère(nt) un (des) verrou(s) et qu’aucun d’entre eux ne peut traiter sa demande à moins que l’autre ne libère le verrou.
Par exemple, dans l’exemple ci-dessous, le processus 1 et le processus 2 attendent l’un et l’autre que l’autre ait terminé sa requête, ce qui crée un blocage.
Un LiveLock est similaire à un DeadLock, à l’exception des processus qui ne sont pas bloqués pour toujours et qui sont traités en permanence par le CPU. La principale différence entre Deadlock et Livelock réside dans le fait que Livelock réagit après un long délai alors que Deadlock ne le fait jamais.
Dans le cas d’environnements réduits, étant donné que le nombre de transactions créées sur le système est moindre, l’enchevêtrement des processus et les verrous ne sont parfois pas observés dans les tests, ce qui entraîne leur apparition dans la production.
Quelle est ma capacité totale ?
Avec des environnements réduits, vous ne pourrez jamais estimer la capacité réelle de votre environnement. On ne peut pas se contenter d’extrapoler les chiffres. Ainsi, dans les scénarios où votre entreprise attendrait de vous (les ingénieurs de capacité) une capacité de production en temps réel, vous ne seriez probablement pas en mesure de lui donner les chiffres ou vous pourriez finir par donner des chiffres qui ne seraient pas proches de la capacité de l’environnement.
De nombreuses situations de ce type m’ont amené à la conclusion que les tests de performance dans un environnement réduit n’en valaient pas la peine et, par conséquent, chaque fois que je ne dispose pas d’un environnement de capacité suffisante, j’utilise le nuage pour tester mes systèmes. Avec le cloud, je suis en mesure d’identifier les blocages et les problèmes liés à la session. Je m’assure également que l’entreprise et les autres parties prenantes sont informées des risques liés aux tests dans un environnement virtuel (si la production se fait sur une infrastructure physique).
Je voudrais donc terminer en disant que les outils de planification de la capacité donnent des chiffres qui échouent en production. D’autre part, ces outils sont beaucoup trop chers. Si vous êtes un analyste de tests de performance (ou si vous avez un expert en tests de performance dans votre équipe) et que les concepts sont bien compris et ancrés, vous devez étudier le système, son architecture, ses utilisateurs professionnels et comprendre leurs exigences. Sur cette base, vous devez planifier le test (et donc l’environnement) de manière à reproduire la plupart des problèmes de performance dans l’environnement de test et à ne permettre à aucun d’entre eux de se déplacer dans l’environnement de production. Dans mon prochain article, j’expliquerai comment planifier un test de manière à ce qu’il imite un scénario de production et nous aide à identifier un maximum de problèmes de performance.
