Le pourquoi, quand et comment du test de montée en charge ?

#méthode#outil#performances

Pourquoi cela est nécessaire ?

La question peut paraître obsolète car désormais une ou plusieurs phases de tests de montée en charge font parties intégrantes de la majorité des processus de développement d’une nouvelle application.

Cependant, il existe encore des sites déployés en production sans phase de test sous prétexte que l’application fonctionne correctement lorsque l’on explore le site et que le temps de réponse est satisfaisant.

  • Mais combien d’utilisateurs simultanés l’application tolère-t-elle ?
  • Quelle est la dégradation de performance face à un nombre d’utilisateurs croissants ?
  • Quel est le composant technique de l’architecture transactionnelle qui défaillira le premier en cas de charge importante ?
  • Les accès concurrents à tous les services techniques sont-ils correctement gérés ?

De nombreux aspects techniques émergeants des architectures web sont à prendre en compte :

  • Centralisation des traitements : contrairement au client/serveur, il faut être en mesure de gérer un partage de ressources, les accès concurrents, des pools d’accès aux base de données, etc.
  • Problématique de dimensionnement : nombre de serveurs, puissance des processeurs, taille mémoire, espace disque, bande passante, etc.
  • Complexité des architectures : les architectures contiennent de plus en plus de maillons techniques pour une seule transaction, il faut tester chaque partie afin d’assurer le fonctionnement de l’ensemble
  • Choix techniques : les services web sont-ils plus performants que des échanges HTTP/XML ? quel est le serveur d’applications le plus performant dans votre contexte ?

La mise en œuvre de tests de montée en charge permet, s’ils sont complètement maîtrisés, de répondre à la majorité des besoins exposés.

Quel est le meilleur moment pour réaliser un benchmark ?

Il est souvent trop tard lorsque l’on s’interroge au sujet de la mise en place de tests de montée en charge. En principe, on se pose des questions lorsqu’un problème est survenu ou lorsque l’on émet des doutes sur le bon fonctionnement de son architecture.

Evidemment, l’idéal serait de réaliser des tests de montée en charge à chaque phase du projet mais cela n’est pas toujours envisageable.

Voici les différentes phases d’un projet et l’intérêt de réaliser une étude de performances pour chacune des étapes :

  • Prototypage : des choix techniques s’imposent afin de définir au mieux le produit ou la technologie la plus adaptée aux besoins
  • Développement : l’anticipation des dysfonctionnements permet ainsi de bâtir une architecture saine au niveau du code applicatif
  • Homologation ou recette : il s’agit de la phase la plus propice pour réaliser un test de montée en charge car les développements sont suffisamment stabilisés et il est parfois encore possible d’intervenir sur une partie des développements.
  • Pré-production : la réalisation des tests de charge va permettre de correctement dimensionner l’architecture en cas de problèmes observés à ce niveau (mémoire, CPU, etc.) et de finaliser les paramétrages des briques techniques (taille des pools de connexion vers la base de données, nombre de processus, etc.)
  • Production : la plupart du temps, ces tests se déroulent dans l’urgence mais les consultants d’Osaxis sont habitués à cela

Comment s’y prendre ?

Un test de montée en charge consiste à solliciter (mettre en charge) une architecture, un site ou une application Web de la même manière qu’en situation d’exploitation. Concrètement, il s’agit de reproduire le comportement d’un nombre important d’utilisateurs à l’aide d’outils spécialisés, de manière à mesurer les performances de l’architecture testée.

Osaxis dispose d’une méthodologie qui est résumée par ces différentes étapes :

  • Formalisation du besoin : choix du type de charge, du type de test, de l’outil, etc.
  • Préparation à la mise en oeuvre : mise en place de l’architecture, sensibilisation des intervenants et écriture des scripts
  • Exécution des tests : respects de certaines règles fondamentales et monitoring de l’architecture
  • Analyse des résultats : 4 axes d’analyse (cartographies, ressources, performances et fiabilités)
  • Proposition d’optimisations et accompagnement pour les appliquer

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 ».