Mettre en place un test de charge

loadrunner métrologieSi vous souhaitez connaître les possibilités de votre site ou de votre application web il n’y a que deux possibilités. Attendre le trafic et constater le point de rupture :-( Ce n’est pas très sérieux vis à vis de vos utilisateurs, et encore moins pour votre image. L’autre solution consiste à mettre en place des tests de métrologie. La métrologie c’est la « science des mesures et ses applications », dans notre cas il s’agit essentiellement de simuler une montée en charge afin de mesurer le comportement de l’application et de ses sous systèmes.

Dans la pratique la première étape consiste à modéliser un utilisateur (son parcours, ses actions, etc…). Il est possible de créer plusieurs types d’utilisateur afin d’avoir un test cohérent avec la réalité. Le piège étant de ne tester qu’un type d’utilisateur en oubliant que dans la réalité il existe toujours des utilisateurs qui sortiront du parcours “prévu”. Ensuite il faut déposer ces scénarios sur des “injecteurs”, qui seront en charge de simuler les internautes (ou autres acteurs de votre système).

Il s’agit en général de serveurs dédiés à cette activité, ils disposent simplement des “robots” en charge de réaliser les parcours pré-définis. Dernière étape mettre en place des “capteurs” afin d’enregistrer le comportement de votre site et/ou application web. Ensuite c’est le départ de la “campagne de tir“, elle permet de mettre en oeuvre les scénarios et de mesurer le comportement de l’application.

HP-LoadRunner_ControllerIl existe de nombreux outils pour réaliser ce type de test de charge. Dans le domaine du libre JMeter est assez répandu. Il permet de mettre en place des campagnes relativement simple en simulant quelques centaines d’utilisateurs simultanés. Au délà d’un certains volume, ou quand la compléxité des scénarios augmente il est préférable d’investir dans un outil dédié. La grille des tarif est assez large, NeoLoad (de l’éditeur Neotys) permet par exemple de réaliser des tirs nombreux et précis (plusieurs milliers d’utilisateurs simultanés). Le coût variant en fonction de la charge, il varie de  quelques milliers d’Euros à 20K€ ou 30K€.

Ensuite pour des utilisations massives et très fréquentes ou pour un département spécialisé dans ce genre de chose il existe HP LoadRunner. Avec cet outil les tarifs s’envolent et il faut compter en centaines de milliers d’Euros la licence. Nous sommes là dans l’outil industriel.

Quelque soit votre budget il existe donc des solutions (il est aussi possible de louer ces applications). A vous de voir si elles correpondent à votre besoin. Mais je vous conseille vivement de programmer ce genre de test. Il vous permettrons de trouver les “bootleneck” de votre application.

Vous éviterez ainsi les problèmes le jour ou votre application sera sous les projecteurs, ce que je vous souhaite !

Comme d’habitude, n’hésitez pas à partager vos expériences, et à citer les sociétés/logiciels que j’ai oublié (comme QALoad de Compuware que je ne connais pas bien). J’en profite pour signaler que je n’ai aucun intérêt dans toutes les sociétés citées sur ce blog !


Sur le même thème :

  • Pas d article sur ce thème

6 Responses to “Mettre en place un test de charge”

  1. Thomas says:

    Bonjour, et meilleurs voeux,

    Personnellement je trouve que la partie “capteurs”, juste évoquée, est bien plus riche et plus intéressante :) Que surveiller à toutes les couches de l’archi, définir les métriques, les récolter, rassembler, corréler, … Pas d’échappatoire : il faut bien alors descendre au niveau de la gestion de mémoire virtuelle par l’OS, du fonctionnement des disques, du réseau, du code, des middlewares, etc., bref, un excellent prétexte pour connaître son archi à tous les niveaux, ce qu’on ne fait pas souvent de manière aussi exhaustive.
    Et les outils natifs de l’OS permettent souvent de mettre tout de suite les mains dedans.

    PS : voici quelques autres outils pour la charge : OpenSTA, Tsung. MS avait aussi un “Application Center Test” assez fruste, je ne sais pas ce qu’il est devenu.

  2. Marc says:

    Bonjour Thomas,

    La partie capteur permet effectivement de bien comprendre comment l’OS se comporte quand l’application testée est en charge. Cet article a pour but de faire découvrir ce type de test, de manière générale sans trop entrer dans le détail.
    Par contre, si tu as des informations, liens intéressants sur cette partie n’hésite pas à nous les communiquer.

    Concernant OpenSTA je ne suis pas sur qu’il soit très à jour, par ailleurs il pose problème lors de tests https (gestion des certificats problématique).

    Merci pour ton commentaire en tout cas,
    Marc

  3. yut says:

    Bonjour,

    Interessant mais pourriez-vous faire des articles plus détaillés sur ce sujet qui me semble essentiel et dont je ne connais pas grand chose.

    Merci

  4. François says:

    Bonjour,

    pour avoir testé pas mal d’outils de test de charge (OpenSTA, Mercury LoadRunner, MS WebApplicationStressTool, SilkPerformer, Neoload, JMeter, SOAPUI pour les Webservices…) il ressort que :

    Mercury LoadRunner (ou HP LoadRunner) est l’outil le plus aboutit dans la mesure où il est possible de tester pratiquement toutes les applications Web, WebServices, Clients lourd, Java, Ajax, Siebel, etc. C’est un outil plutôt couteux mais finalement pas si compliqué que cela à mettre en oeuvre.

    Neoload est financièrement plus abordablev que LoadRunner, il se cantone aux applications de type web. L’outil possède une qualité énorme : la prise en main est enfantine, c’est l’outil dont la prise en main est quasiment immédiate. Dans mon équipe j’ai des durs qui hors contexte ne parlent que de JMeter mais qui une fois face à la nécessité de réaliser des tests de charges sont contents d’utiliser Neoload.

    SAOPUI est excellent pour les tests de Webservices.

    Le reste :
    JMeter : pas mal, mais la prise en main est complexe à mon goût surtout si on a déjà touché à LoadRunner et à Neoload. Cet outil gratuit permet de tester beacoup de choses, il y a toutefois des choses pénibles outre sa relative complexité : le support difficile du SSL par exemple. Pour moi, le temps nécessaire à s’approprier l’outil approche le coût de licence de neoload.

    OpenSTA : assez complexe, son développement semble stoppé depuis 2002.

    MS WebApplicationStressTool : dépassé, convient pour des applications/sites simples. Gratuit.

    SilkPerformer de Borland : trop complexe.

    Par ailleurs, effectivement en complément du tests de charge, il est nécessaire de surveiller les différentes couches mises en oeuvre par une application. Les moniteurs système sont là pour ça, certains outils sont capables de collecter à distance ces moniteurs (CPU, mémoire etc). Pour les applications de type Java J2EE, l’utilisation d’un outil de profilage comme Yourkit permet de bien monitorer une application et de détecter des fuites mémoire.

    Voila.

  5. Marc says:

    Merci beaucoup pour ton commentaire François !

    Concernant JMeter c’est effectivement plus complexe que NeoLoad (ce n’est pas comparable d’ailleurs) mais si les moyens financiers sont proches de zéro l’outil badboy peut simplifier la tâche de configuration JMeter.

  6. Paul says:

    Bonjour,

    Merci François pour vos commentaires.
    Pour info, nous venons de sortir une nouvelle version de NeoLoad qui permet maintenant d’utiliser le cloud pour ses tests de charge.
    L’avantage est de permettre de compléter vos tests existants avec des tirs depuis l’extérieur du firewall, pour tester l’application de bout en bout. De même,
    il est possible de déployer en quelques minutes de nombreux injecteurs de charge.
    Je serais heureux d’avoir vos retours sur notre nouvelle version si vous avez l’occasion de l’essayer! (http://www.neotys.com)

    Paul Baratto
    Neotys

Leave a Reply