Tester les performances de son API

Réaliser des tests de performances sur une application n’est jamais simple. Il est en effet assez complexe de simuler une montée en charge réaliste, ainsi qu’une activité utilisateur cohérente. Nous allons explorer quelques pistes pour y parvenir.

video: https://www.youtube.com/embed/tiViq4PrghI

Test de performances API – Qu’est-ce qu’on mesure ?

Premièrement, lorsqu’on parle de performance, il faut s’entendre sur ce que l’on mesure. Ici, nous nous consacrerons uniquement à la mesure des performances brutes d’une application web (de son API) et/ou d’un service unitaire. Nous passerons donc volontairement outre le temps de chargement des pages côté client et les temps de transfert pour nous focaliser sur le temps de sortie ou de réponse de l’APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données.. Nous partons du principe que votre application est notamment composée d’une API de services RESTREST (REpresentational State Transfer) est un style d'architecture logicielle qui fonctionne sous un certain nombre de contraintes. (le raisonnement reste le même pour des services SOAPSOAP (Simple Object Access Protocol) est un protocole de communication. ).

Performance API – Etape 1 : Mesure et enregistrement des appels

La première étape consiste à mesurer et enregistrer les appels réalisés par votre application. Parmi la kyrielle d’outils disponibles sur le marché, nous vous conseillons d’utiliser jMeter en mode proxy pour enregistrer l’intégralité des appels à votre API. Il existe de nombreux tutoriaux sur internet pour réaliser ceci. Une fois votre flux d’appels créé, il convient de le paramétrer.

Pour cela, nous vous conseillons l’approche suivante (facile à réaliser sur jMeter, mais qui peut se réaliser sur tout outil de benchmark) :

• 1 – Variabiliser les utilisateurs : ceci se fait simplement via un fichier CSV.
• 2 – Créer plusieurs scénarios utilisateurs : en effet, vos utilisateurs ne vont pas tous réaliser les mêmes actions au même moment.
• 3 – Rajouter un thinktime important entre chaque appel à l’API : un changement de page côté utilisateur va surement déclencher un ou plusieurs appels à l’API, mais entre deux pages, il ne faut pas oublier que votre utilisateur réfléchit (si si, c’est vrai ! j’en vu un faire une fois…). Il faut compter au moins 4/5 secondes entre deux interactions d’un utilisateur.
• 4 – Varier les écritures et les lectures : vos scénarios doivent comporter un ratio écriture / lecture d’environ 80/20. Pourquoi ? Car la majorité des applications passent 80% du temps en lecture d’informations depuis la base, et environ 20% en écriture. Essayez donc de garder ce ratio entre les différents scénarii.
• 5 – Si possible, variabiliser les lectures : souvent les BDD mettent en cache les requêtes que vous avez effectuées. Ainsi, si vous répétez souvent le même scénario, il est probable que vous serveur de BDD accélère grandement les choses, mais ce n’est pas un cas réel d’utilisation.

Performance API – Etape 2 : Test !

Lorsque vous avez paramétré votre outil, vous êtes prêt pour lancer vos tests de performances.

Avant toute chose, il convient de réaliser une phase de warmup du serveur. Qu’entend-t-on par là ? Si vous souhaitez tester avec 100 utilisateurs en simultané, ne les faites pas démarrer tous en même temps ! Vous allez écrouler les performances de votre serveur et ceci ne sera pas du tout réaliste. Nous vous conseillons donc de les faire démarrer de manière progressive, par exemple 1 toutes les 30 secondes… oui, c’est sûr que c’est plus lent pour réaliser ses tests, mais c’est plus infiniment plus réaliste. De plus, en réalisant ceci, les utilisateurs se répartiront naturellement sur les différentes étapes de votre scénario.

Petit conseil supplémentaire : réaliser avant toute autre chose un test de performance unitaire de chaque service, afin de mesurer le temps unitaire de chaque appel. Ceci vous permettra d’avoir un point de comparaison et de mesurer la dégradation de la performance en fonction de la montée en charge.

Pour vous donner un ordre de grandeur, un serveur correctement dimensionné doit être capable de gérer 500 utilisateurs. Si ce n’est pas le cas, soit votre test est mal fait, soit votre application présente un problème de performance.