De plus en plus, nous sommes amenés à réaliser des tests de charge sur nos applications afin de déterminer notamment combien d’utilisateurs une configuration donnée est en mesure d’encaisser. Toutefois, il faut veiller à bien les mettre en place pour avoir des résultats significatifs et surtout utilisables, car mal réalisés, ces tests ne signifient rien. L’objet de cet article est là, il ne s’agit pas de présenter tel ou tel outil mais plutôt d’expliquer comment bien mettre en oeuvre ces tests.
Débloque les + belles offres tech en 10 mins
Déterminez les fonctionnalités réellement utilisées dans votre application
La première chose à faire pour un test de charge est de déterminer son scénario, autrement dit quelles pages vont être appelées par l’outil de test. Il se trouve en effet que seule une partie des fonctionnalités de votre application sera utilisée, et non pas la totalité de celles-ci. Par exemple sur un réseau social les fonctions utilisées seront celles d’affichage d’autres profils, et aussi le journal d’actualités de vos contacts, par contre la gestion des comptes utilisateur sera nettement moins usitée. Donc on peut tout à fait exclure cette dernière du scénario.
Ensuite, une fois ces fonctionnalités déterminées, il convient de réaliser à l’aide de votre outil un ou plusieurs parcours utilisateur, qui seront exécutés en parallèle lors du test de charge. Ces parcours doivent conçus de telle façon qu’ils puissent être variabilisés. Par exemple si votre parcours se base à un moment sur l’id d’un profil utilisateur, ce dernier devra être variabilisé de façon à ce que cet id puisse changer. En effet, si lorsque vous lancez votre test tous les « utilisateurs » effectuent absolument le même parcours en allant viser les mêmes entités, les résultats seront faussés en raison notamment des différents caches applicatifs ou système.
Prévoyez un jeu de données conséquent
Comme vu ci-dessus votre application doit être testée sur un jeu de données suffisamment bien réparti pour que le test soit significatif. En effet il faut éviter au maximum de rentrer dans les caches, ceux-ci faussant vos résultats. Par conséquent n’hésitez pas à générer de gros ensembles de données, ou à prendre celles de production.
Contrôlez les réponses du serveur
Dans votre scénario de test de charge, par défaut, les réponses du serveur ne sont pas contrôlées. Autrement dit, si le serveur retourne un code entre 200 et 399 la réponse sera considérée comme valide, et au-delà elle sera en erreur. Sauf que de nombreuses applications peuvent retourner un code 200 sans pour autant renvoyer la réponse attendue, pour une raison ou une autre. Par conséquent prenez toujours comme habitude de positionner des assertions réponse qui contrôlent le résultat renvoyé par le serveur. Le plus simple pour les réaliser est de rechercher un pattern textuel dans la réponse, qui sera caractéristique d’une réponse vraiment en succès.
Testez votre application, pas votre réseau
Une approche naïve consiste à dire qu’on peut lancer le test de charge depuis votre réseau d’entreprise pour tester une application hébergée dans le cloud ou chez un hébergeur tel qu’OVH. Si vous le faites, vous risquez principalement de tester… votre bande passante entre votre réseau d’entreprise et l’hébergeur. En effet, bien souvent le réseau internet fait office de goulet d’étranglement entre vous et un serveur distant, et c’est le cas ici. Dès lors les temps de réponse que vous verrez ne seront pas significatifs, car ils seront perturbés par la latence réseau. Bref, pour mener à bien vos tests, vous devez les tirer depuis une ou plusieurs machines qui sont sur le même réseau physique que la machine où est hébergée l’application à tester.
Ayez un matériel conséquent pour tirer vos tests
On pourrait être tenté de se dire que la machine d’où les tests sont tirés n’a pas besoin d’être une bête de course… Erreur ! Dans le cas de JMeter par exemple, si vous lancez 100 threads de requêtes simultanément depuis un PC de bureau à base de Core i3 ou de Core2 Duo et 4 Go de RAM vous avez toutes les chances de voir votre machine littéralement s’effondrer. Et dans ce cas les résultats de vos tests ne seront pas significatifs car ils auront été faussés par la machine qui rame. Dès lors, on peut dire sans se tromper que la machine depuis laquelle les tests sont tirés doit avoir autant de mémoire et de CPU que la machine cible.
Cas particulier : plusieurs applications hébergées sur le même serveur
Vous êtes dans la situation suivante : par mesure d’économie votre serveur doit héberger plusieurs applications. Il ne s’agit pas d’hébergement cloud mutualisé comme certains prestataires peuvent le fournir, mais bien d’un choix qui est d’héberger plusieurs Tomcat sur une même machine ou un même Tomcat avec plusieurs applications simultanées. Dès lors, pour que votre test soit significatif, vous devez tester non pas votre application mais toutes les applications hébergées sur le serveur simultanément. En effet, rien ne dit sinon que quand vous aurez mis une charge importante sur une autre application que la vôtre cette dernière réagisse pareil à une charge donnée.
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Trucs et astuces pour l’optimisation des performances en Java/JEE
- Trucs et astuces Linux
- Utilisation efficace de la base de données dans vos applications web
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
