Brevet FR2985335A1 — publié le 20130705

La présente invention concerne le domaine des tests de performance d'infrastructures informatiques. De telles infrastructures informatiques sont par exemple des calculateurs hautes performances, généralement désignés sous leur appellation anglo-saxonne « clusters » HPC (HPC étant le sigle de « High Performance Computing »). Il peut également s'agir de réseaux de serveurs (par exemple Web). Les tests de performance (« Benchmark » en terminologie anglo- saxonne) peuvent avoir pour objectif de résoudre des problèmes de performance existants d'une application, de dimensionner une infrastructure nécessaire pour une application en fonction d'une utilisation donnée, de valider les performances, l'endurance, la robustesse d'une application, de comparer des évolutions (briques logicielles, version d'application, optimisations, etc.), ou autre. Les applications (ou logiciels) de test de performance permettent de simuler plusieurs utilisateurs simultanément. Par exemple, pour une infrastructure informatique d'application Web (un réseau de serveurs Web), l'application de test est capable d'envoyer vers l'infrastructure un très grand nombre de requêtes (par exemple au format HTML), comme si elles provenaient d'utilisateurs simultanés différents. Ces applications permettent de créer un ou plusieurs scénarios de test en choisissant une ou plusieurs requêtes à faire exécuter par l'architecture testée et en choisissant un débit de requêtes pour chaque scénario. Les applications de test effectuent un certain nombre de mesures (temps de réponse de l'infrastructure, taux d'erreurs, ou autre) et génèrent un rapport de test. Une application de test connue, développée par Apache Software Foundation, est JMeter. Il s'agit d'un outil de test de charge en langage JAVA. De manière générale, un test de performance d'infrastructure informatique, peut se dérouler en plusieurs étapes. Dans une première étape, la stratégie de test est définie, avec notamment : - la définition du contexte technique de l'architecture testée, - le choix d'un ou plusieurs scénarios et la pondération de ces scénarios (c'est-à-dire la définition de l'importance relative des uns par rapport aux autres), - la détermination de la volumétrie cible (c'est-à-dire le débit de requêtes souhaité pour le test), - la détermination des types de requêtes à envoyer en fonction des objectifs du test, - la définition de l'architecture testée, - la détection des pré-requis. Ensuite, l'environnement du test est mis en place. Il s'agit par exemple d'appliquer une certaine configuration à l'architecture informatique testée pour pouvoir tester cette configuration en particulier. Les scénarios de test sont ensuite définis au moyen d'applications de test (par exemple JMeter) puis modifiés pour être paramétrables. Ensuite, à partir de ces définitions, les jeux d'injection d'instructions sont construits. Il s'agit de définir les paramètres des requêtes à envoyer vers l'infrastructure testée pour mettre en oeuvre les scénarios (par exemple sous forme de fichier CSV, sigle de « Comma-separated values », ou d'un export d'une base de données). Pour effectuer les mesures de performances, il peut être nécessaire de développer des sondes de mesure spécifiques à une grandeur particulière. Des scripts d'ordonnancement sont ensuite générés pour exécuter de façon chronologique les tâches nécessaires à la mise en oeuvre des requêtes selon les jeux d'injection. Enfin, les requêtes sont exécutées lors d'une « campagne de tir» et les résultats sont mesurés et analysés pour générer un rapport. Avant le lancement de la campagne de tir, la plupart des étapes évoquées ci-dessus nécessitent l'intervention d'un utilisateur qui supervise le 30 test. En effet, outre la définition la stratégie de test (scénarios), l'utilisateur doit spécifier de manière très précise l'ensemble des paramètres nécessaires à l'application de test pour lancer de manière coordonnée l'ensemble des instructions vers l'architecture testée. Pour une campagne de tir légère, cela peut se concevoir, si le paramétrage est réalisé par un utilisateur très expérimenté. Par contre, lorsque l'architecture informatique à tester est complexe et comporte un très grand nombre de matériels et de logiciels, comme c'est le cas pour les clusters HPC, les scénarios à exécuter et les instructions sous-jacentes son démultipliées. La tâche peut alors devenir presque impossible, même pour un utilisateur confirmé. Il existe donc un besoin pour améliorer les tests d'infrastructures informatiques, notamment pour les clusters HPC. La présente invention s'inscrit dans ce cadre. Un premier aspect de l'invention concerne un procédé de génération de fichier d'injection pour une mesure de performance d'infrastructure informatique, comportant les étapes suivantes de : - lecture d'un fichier de configuration de test comportant au moins une définition d'au moins un scénario de test, ledit fichier de configuration comportant au moins un paramètre de test, - calcul d'au moins une variable de test à partir d'au moins un paramètre du premier fichier de configuration, - génération d'un fichier d'injection comportant au moins une requête à destination de l'infrastructure informatique, à partir d'au moins ladite au moins une variable de test calculée. Ainsi, il est possible de générer un fichier d'injection avec les paramètres de l'injection, sans qu'il soit nécessaire pour l'utilisateur de configurer le module d'injection mettant en oeuvre l'envoi des requêtes à destination de l'infrastructure informatique testée (campagne de tir de requêtes). Une infrastructure informatique peut s'entendre au sens matériel et/ou au sens logiciel. Plusieurs aspects d'une telle infrastructure peuvent être testés : capacité à répondre à un volume de requêtes (test de charge), capacité à répondre à un type de requête après une modification (logicielle et/ou matérielle), ou autre. Une infrastructure informatique peut être testée dans sa totalité ou en partie. Une infrastructure peut être testée selon une ou plusieurs configurations disponibles. En générant un fichier d'injection comportant les variables d'injection déjà calculées, il n'est plus nécessaire pour l'utilisateur d'intervenir pour configurer le module d'injection pour cadencer la campagne de tir. Il est ainsi possible de maîtriser de façon très précise le nombre de scénarios exécutés par unité de temps. Par exemple, le fichier d'injection est initialisé à partir d'un fichier de base. La génération du fichier d'injection est ainsi simplifiée. Le procédé peut en outre comporter une étape de substitution d'au moins un marqueur du fichier de base par une variable de test calculée. Par exemple, au moins l'une des variables de test parmi les suivantes est calculée : - un nombre de processus à faire exécuter par l'infrastructure informatique, - une durée de démarrage de processus à faire exécuter par l'infrastructure informatique, - une durée de test, et - une durée d'itération d'un scénario de test durant le test. Par exemple, l'infrastructure informatique est un calculateur hautes performances (ou cluster HPC). Un deuxième aspect de l'invention concerne un procédé de mesure de performance d'infrastructure informatique, comportant les étapes suivantes de : - lecture d'un fichier d'injection généré selon le premier aspect, - envoi d'au moins une requête du fichier d'injection à destination de l'infrastructure informatique selon le fichier d'injection reçu, et - mesure de performance de l'infrastructure informatique en fonction de l'exécution de ladite au moins une requête par ladite infrastructure informatique. Un troisième aspect de l'invention concerne des programmes d'ordinateur ainsi que des produits programme d'ordinateur et des supports de stockage pour de tels programmes et produits, permettant la mise en oeuvre de procédés selon le premier et/ou le deuxième aspect de l'invention, lorsque les programmes sont stockés dans une mémoire d'un dispositif de génération de fichier d'injection et/ou de mesure de test de performance et exécutés par un processeur de tels dispositifs. Un quatrième aspect de l'invention concerne un dispositif de génération de fichier d'injection pour une mesure de performance d'infrastructure informatique, comportant une unité de traitement configurée pour lire un fichier de configuration de test comportant au moins une définition d'au moins un scénario de test, ledit fichier de configuration comportant au moins un paramètre de test, calculer au moins une variable de test à partir d'au moins un paramètre du premier fichier de configuration, et générer un fichier d'injection comportant au moins une requête à destination de l'infrastructure informatique, à partir d'au moins ladite au moins une variable de test calculée. Par exemple, l'unité de traitement est en outre configurée pour initialiser le fichier d'injection à partir d'un fichier de base. L'unité de traitement peut en outre être configurée pour substituer au moins un marqueur du fichier de base par une variable de test calculée. Au moins l'une des variables suivantes peut être calculée : - un nombre de processus à faire exécuter par l'infrastructure informatique, - une durée de démarrage de processus à faire exécuter par l'infrastructure informatique, - une durée de test, et - une durée d'itération d'un scénario de test durant le test. Un cinquième aspect de l'invention concerne un dispositif de mesure de performance d'infrastructure informatique, comportant une unité de traitement pour lire un fichier d'injection généré selon le premier aspect, envoyer au moins une requête du fichier d'injection à destination de l'infrastructure informatique selon le fichier d'injection reçu, et pour mesurer une performance de l'infrastructure informatique en fonction de l'exécution de ladite au moins une requête par ladite infrastructure informatique. Un sixième aspect de l'invention concerne un système de mesure de performance d'infrastructure informatique comportant : - un dispositif de génération de fichier d'injection selon le quatrième aspect, et - un dispositif de mesure de performance selon le cinquième aspect. Les objets selon les deuxième, troisième, quatrième, cinquième et sixième aspects de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect. Les dispositifs et le système peuvent comporter des moyens pour la mise en oeuvre de caractéristiques optionnelles évoquées pour le premier ou le deuxième aspect en termes de procédé. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la présente description détaillée qui suit, à titre d'exemple non limitatif, et des figures annexées parmi lesquelles : la figure 1 illustre un contexte général de mise en oeuvre de modes de réalisation ; - les figures 2 et 3 sont des organigrammes d'étapes mises en oeuvre selon des modes de réalisation ; et - la figure 4 illustre schématiquement un dispositif selon un mode de réalisation de l'invention. Dans la description qui suit, il est présenté un outil pour configurer un fichier d'injection de requête de manière automatique afin de l'utiliser pour une « campagne de tir » d'une application de test d'infrastructure informatique. Une campagne de tir est une suite d'opérations en grand nombre qui doivent s'exécuter dans un ordre bien précis. L'oubli d'une opération ou son exécution dans un mauvais ordre peut avoir des incidences sur la réussite de la campagne de tir et sur son analyse. Pour éviter ce type de problème, l'ensemble des actions et des opérations sont automatisées dans un « script d'ordonnancement ». Les actions et opérations peuvent être regroupées selon différentes familles, notamment : - démarrage/arrêt des services exécutés par les différents équipements de l'infrastructure informatique testée, - démarrage/arrêt des sondes de mesure sur les différents équipements de l'infrastructure informatique testée, - démarrage/arrêt de l'injection, - collecte des différents historiques d'évènements (aux niveaux logiciel, machine, ou autre) sous forme de fichiers « log », - validation des résultats de mesure des sondes, - génération de graphiques à partir des résultats de mesure, - création d'une archive avec l'ensemble des données du test afin d'assurer la traçabilité. La figure 1 illustre un contexte général de mise en oeuvre de modes de réalisation. Une infrastructure informatique 10, qui met en oeuvre une ou plusieurs applications logicielles est testée. Cette infrastructure est par exemple 20 un cluster HPC. Il est possible d'envisager d'autres infrastructures informatiques. A cet effet, un dispositif d'injection 11, mettant en oeuvre une application de test, envoie vers l'infrastructure 10 un ensemble de requêtes (« campagne de tir ») que l'infrastructure exécute. Le dispositif reçoit par 25 ailleurs de l'infrastructure des résultats d'exécution de ces requêtes et des données de mesure de performance. Pour exécuter la campagne de tir, le dispositif d'injection reçoit ou lit un fichier d'injection instancié 12 « benchmark ». Ce fichier d'injection est généré par un module d'ordonnancement 13. Ce module d'ordonnancement 30 peut faire partie du dispositif d'injection ou faire partie d'un autre dispositif spécifiquement dédié à la génération du fichier d'injection 12. Pour générer le fichier d'injection 12, le module d'ordonnancement utilise un fichier de base 14 « template » et un fichier de configuration 15 « config ». Le module d'ordonnancement exécute un script d'ordonnancement, par exemple écrit en langage Bash, qui automatise les tâches liées à la mesure de performance (Benchmark) d'une application informatique. Ce script peut comporter les étapes suivantes, implémentées sous forme de fonctions, notamment : - configurer le module d'injection pour exécuter la campagne de tir, - rediriger les requêtes vers les éléments (matériels ou logiciels) de l'infrastructure), - copier, ou calculer, les paramètres d'injection dans le fichier d'injection, arrêter les sondes de mesure, - arrêter les services de l'infrastructure informatique, - purger la mémoire du module d'injection pour le réinitialiser, - démarrer les services de l'infrastructure informatique, - démarrer les sondes de mesure, - injecter les requêtes vers l'infrastructure informatique, - arrêter les services, - arrêter les sondes, - collecter les données de mesure, - démarrer les services, - analyser les données de mesure, - archiver les données de mesure. L'étape « injecter » appelle l'exécution du fichier d'injection par le dispositif d'injection. L'étape « copier » consiste à calculer les paramètres nécessaires à la génération du fichier d'injection. Lors de cette étape, le module d'ordonnancement lit le fichier de configuration 15 et prépare le fichier d'injection 12 à destination du dispositif d'injection. Pour chaque scénario dans le fichier de configuration, des variables d'injection sont calculées afin de les intégrer au fichier d'injection et permettre au dispositif d'injection de cadencer les instructions envoyées vers l'infrastructure informatique testée. La figure 2 est un organigramme d'étapes mises en oeuvre lors de la génération du fichier d'injection. Ces étapes sont par exemple mises en oeuvre par le module d'ordonnancement. Lors de l'étape S20, le fichier de configuration est lu pour connaître l'ensemble des scénarios à exécuter lors du test et connaître les paramètres de ces scénarios. Ensuite, lors de l'étape S21, le fichier d'injection est initialisé sur la base d'un fichier de base. Ce fichier de base peut par exemple avoir un format adapté au dispositif d'injection avec des champs à remplir. Lors de l'étape S22, il est déterminé s'il reste des scénarios à traiter dans le fichier de configuration. Si c'est le cas (OUI), un calcul des variables d'injection est effectué lors de l'étape S23 en fonction des paramètres du scénario considéré dans le fichier de configuration. Les variables calculées sont ensuite intégrées au fichier d'injection lors de l'étape S24. Par exemple, il s'agit de substituer dans le fichier de configuration des marqueurs par des valeurs calculées (par exemple, remplacer le marqueur %NOMBRE_THREADS% par la valeur 12). Lorsque tous les scénarios ont été considérés (étape S22, NON), le fichier d'injection est généré lors de l'étape S25 puis envoyé vers le dispositif d'injection pour son exécution. Si la génération du fichier d'injection et l'injection sont mises en oeuvre par le même dispositif, le fichier généré est transmis au module mettant en oeuvre l'injection. Le calcul automatique des variables d'injection permet de s'affranchir de l'intervention d'un utilisateur pour paramétrer complètement le dispositif d'injection. Après l'intégration des variables d'injection dans le fichier d'injection, la campagne de tir est intégralement décrite dans le fichier d'injection. Ce fichier peut par exemple être au format XML (« eXtended Markup Language »). Une fois le fichier d'injection généré, il peut être modifié, via une interface utilisateur du dispositif d'injection. Un scénario de test comporte un groupe de processus légers (« threads » en terminologie anglo-saxonne). Ces groupes sont caractérisés notamment par : - le nombre de processus, - la durée de démarrage des processus (durée aussi connue sous le nom de « rampe » ou « ramp up » en anglais, - le nombre d'itération du scénario que réalise chaque processus, - la durée de l'injection (qui correspond à la durée du scénario multipliée le nombre d'itérations, à laquelle s'ajoute une partie de la durée de la 10 rampe), - le délai avant le démarrage de l'injection, - une liste d'actions à exécuter (requêtes) qui constituent le scénario. Les processus d'un même groupe exécutent le même scénario de 15 manière répétitive. Un scénario de test peut notamment se définir selon : - la mesure de l'heure de début du scénario, au début du scénario, - la mesure de l'heure de début de la requête, avant chaque requête, 20 - une ou plusieurs requêtes (actions) qui consistent par exemple à émettre une requête HTTP vers un serveur Web, - après chaque requête, une attente variable qui permet de conserver le débit constant, - après chaque attente variable, une attente fixe qui simule le temps 25 de réflexion et de saisie de l'utilisateur de l'infrastructure informatique testée, - à la fin du scénario, une attente variable qui permet de conserver le débit constant. La durée d'attente variable après une requête est calculée en soustrayant la durée réelle de la requête à la valeur de la variable d'injection 30 DURES REQUETE, selon la formule : DUREE REQUETE - (Heure courante - Heure de début de la requête). Par exemple, si la variable DUREE_REQUETE vaut 2000 ms et que la durée réelle de la requête est de 450 ms, l'attente sera de 1550 ms. L'unité donnée ici est la milliseconde, mais peut être différente, par exemple afin de s'adapter au format d'entrée (fichier de configuration) ou de sortie. La durée d'attente variable en fin de scénario est calculée en soustrayant la durée réelle du scénario à la valeur de la variable d'injection DUREE ITERATION, selon la formule : DUREE_ITERATION - (Heure courante - Heure de début du scénario). Par exemple, si la variable DUREE_ITERATION vaut 60000 ms et que la durée réelle de la requête est de 20000 ms, l'attente sera de 40000 ms. Afin de maîtriser le nombre d'itérations exécutés dans un temps donné (débit) pour un scénario, les variables d'injection sont calculées en fonction des paramètres du scénario. Le fichier de configuration définit la liste des scénarios devant être 15 traités, par exemple trois scénarios Si, S2 et S3 : SCENARIOS = "S1 S2 S3". Les paramètres des scénarios sont définis dans le fichier de configuration et sont préfixés par le nom du scénario et le caractère '_'. Lors de la lecture des paramètres, le préfixe et le caractère sont supprimés. 20 Les paramètres d'un scénario sont par exemple : - DELAI TIR - DUREE TIR - DEBIT TIR heure, 25 - DUREE REQUETE : délai avant le démarrage de la campagne de tir, : durée souhaitée de la campagne de tir, : débit de la campagne de tir, en scénarios par : durée maximale d'une requête, utilisée pour calculer un temps d'attente variable en fonction de la durée réelle de la requête, afin de conserver un débit d'injection constant, : nombre de requêtes (par exemple http) dans le scénario, : durée de l'attente de type 1, correspondant à une attente fixe et simulant une attente courte, - NOMBRE REQUETE 30 - DUREE ATTENTE1 - NOMBRE_ATTENTE1 : nombre d'attentes de type 1 dans le scénario, - DUREE_ATTENTE2 : durée de l'attente de type 2, correspondant à une attente fixe et simulant une attente moyenne, - NOMBRE_ATTENTE2 : nombre d'attentes de type 2 dans le scénario, - DUREE ATTENTE3 : durée de l'attente de type 3, correspondant à une attente fixe et simulant une attente longue, - NOMBRE_ATTENTE3 : nombre d'attentes de type 3 dans le scénario, - DUREE_ATTENTE4 : durée de l'attente de type 4, correspondant à une attente fixe et simulant une attente très longue, 10 - NOMBRE_ATTENTE4 : nombre d'attentes de type 4 dans le scénario, - DUREE TEMPO : durée de temporisation en fin de scénario, utilisée pour calculer un temps d'attente variable en fonction des durées théorique et réelle de l'itération, afin de conserver un débit d'injection constant. 15 Pour chaque scénario, les variables d'injection calculées peuvent être: - NOMBRE THREADS : nombre de processus devant être exécutés, calculé en fonction des paramètres du scénario, - DUREE RAMPE durée du démarrage des processus, calculée 20 en fonction des paramètres du scénario - NOMBRE ITÉRATIONS : nombre d'itérations du scénario devant être - DUREE TIR 25 - DELAI TIR - DUREE REQUETE exécutées par chaque thread, : durée réelle du tir, calculé en fonction des paramètres du scénario, : valeur non modifiée par rapport au paramètre du scénario, : valeur non modifiée par rapport au paramètre du scénario, : valeur non modifiée par rapport au paramètre du scénario, : valeur non modifiée par rapport au paramètre du scénario, - DUREE_ATTENTE1 30 - DUREE_ATTENTE2 - DUREE ATTENTE3 : valeur non modifiée par rapport au paramètre du scénario, - DUREE_ATTENTE4 : valeur non modifiée par rapport au paramètre du scénario, - DUREE ITERATION : durée totale d'une itération du scénario, calculée en fonction des paramètres du scénario. Ces variables peuvent être calculées selon les formules suivantes : - DUREE_SCENARIO = (DUREE_REQUETE * NOMBRE_REQUETE) + (DUREE_ATTENTE1 * NOMBRE_ATTENTE1) + (DUREE_ATTENTE2 * 10 NOMBRE_ATTENTE2) + (DUREE_ATTENTE3 * NOMBRE_ATTENTE3) + (DUREE_ATTENTE4 * NOMBRE_ATTENTE4), - NOMBRE_THREADS = (((DUREE_SCENARIO + DUREE_TEMPO) * DEBIT_TIR) + 3599000) / 3600000, (la présence des valeurs 3599000 et 15 3600000 se justifie par l'arrondi de la variable à l'entier supérieur), - DUREE_ITERATION = (NOMBRE_THREADS * 3600000) / DEBIT_TIR, - NOMBRE ITERATIONS = $DUREE TIR / DUREE_ITERATION 20 Si NOMBRE ITERATIONS 1 DUREE RAMPE = DUREE ITERATION DUREE RAMPE REELLE = (DUREE_ITERATION / NOMBRE THREADS) * (NOMBRE_THREADS - 1) 30 Sinon DUREE RAMPE = 0 DUREE RAMPE REELLE = 0 Fin Si - DUREE TIR = DUREE RAMPE REELLE + (DUREE ITERATION * NOMBRE ITERATIONS). La figure 3 est un organigramme d'étapes mise en oeuvre pour un procédé de test d'infrastructure informatique selon des modes de réalisation. Lors d'une étape S30, un fichier d'injection, généré comme décrit ci-avant et reçu, ouvert et lu pour déterminer lors de l'étape S31, un premier scénario à exécuter (OUI). Les requêtes du scénario sont ensuite envoyées lors de l'étape S32, conformément au scénario et au paramétrage de celui-ci. Une étape de mesure S33 est alors mise en oeuvre pour récupérer des résultats de mesure de performance. L'étape S31 est alors de nouveau exécutée pour déterminer s'il reste encore un ou plusieurs scénarios à mettre en oeuvre, si c'est le cas (OUI), les étapes S32 et S33 sont de nouveau mises en oeuvre, sinon (NON), une étape S34 de stockage des résultats de mesure est exécutée. Les résultats obtenus et stockés sont ensuite analysés lors de l'étape S35 et un rapport de test de performance est généré lors de l'étape S36. Un programme d'ordinateur pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention peut être réalisé à partir notamment des organigrammes des figures 2 et 3 et de la présente description détaillée. Un dispositif de génération de fichier d'injection ou de test de performance d'architecture informatique selon un mode de réalisation est décrit en référence à la figure 4. Le dispositif 40 de la figure 4 comporte une unité de mémoire 41 (MEM). Cette unité de mémoire comporte une mémoire vive pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé conforme à l'invention, selon divers modes de réalisation. L'unité de mémoire comporte par ailleurs une mémoire non volatile (par exemple du type EEPROM) pour stocker par exemple un programme d'ordinateur, selon un mode de réalisation, pour son exécution par un processeur (non représenté) d'une unité de traitement 42 (PROC) du dispositif. Par exemple, l'unité de mémoire peut stocker un fichier de base « template » ou un fichier d'injection comme décrit précédemment. Le dispositif comporte par ailleurs une unité de communication 43 (COM), par exemple pour recevoir des fichiers d'injection et/ou des résultats de mesure de performance, et/ou pour envoyer des requêtes vers une infrastructure informatique à tester. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. REVENDICATIONS1. Procédé de génération de fichier d'injection (12) pour une mesure de performance d'infrastructure informatique (10), comportant les étapes suivantes de : - lecture (S20) d'un fichier de configuration de test (15) comportant au moins une définition d'au moins un scénario de test, ledit fichier de configuration comportant au moins un paramètre de test, - calcul (S23) d'au moins une variable de test à partir d'au moins un paramètre du premier fichier de configuration, et - génération (S25) d'un fichier d'injection comportant au moins une requête à destination de l'infrastructure informatique, à partir d'au moins ladite au moins une variable de test calculée. 2. Procédé selon la revendication 1, comportant une étape d'initialisation (S21) du fichier d'injection à partir d'un fichier de base. 3. Procédé selon la revendication 2, comportant une étape de substitution d'au moins un marqueur du fichier de base par une variable de test 20 calculée. 4. Procédé selon l'une des revendications précédentes, comportant le calcul d'au moins une variable de test parmi : - un nombre de processus à faire exécuter par l'infrastructure 25 informatique, - une durée de démarrage de processus à faire exécuter par l'infrastructure informatique, - une durée de test, et - une durée d'itération d'un scénario de test durant le test. 30 5. Procédé de mesure de performance d'infrastructure informatique (10), comportant les étapes suivantes de :- lecture (S30) d'un fichier d'injection (12) généré selon l'une des revendications 1 à 4, - envoi (S32) d'au moins une requête du fichier d'injection à destination de l'infrastructure informatique selon le fichier d'injection reçu, et - mesure de performance (S33) de l'infrastructure informatique en fonction de l'exécution de ladite au moins une requête par ladite infrastructure informatique. 6. Procédé selon l'une des revendications précédentes, dans lequel l'infrastructure informatique est un calculateur hautes performances. 7. Programme d'ordinateur comportant des instructions pour la mise en ceuvre d'un procédé selon l'une des revendications 1 à 6, lorsqu'il est exécuté par un processeur d'un dispositif de génération de fichier d'injection ou d'un dispositif de mesure de performance d'une infrastructure informatique. 8. Dispositif (13, 40) de génération de fichier d'injection (12) pour une mesure de performance d'infrastructure informatique (10), comportant une unité de traitement (42) configurée pour lire un fichier de configuration de test (15) comportant au moins une définition d'au moins un scénario de test, ledit fichier de configuration comportant au moins un paramètre de test, calculer au moins une variable de test à partir d'au moins un paramètre du premier fichier de configuration, et générer un fichier d'injection comportant au moins une requête à destination de l'infrastructure informatique, à partir d'au moins ladite au moins une variable de test calculée. 9. Dispositif selon la revendication 8, dans lequel l'unité de traitement est en outre configurée pour initialiser le fichier d'injection à partir d'un fichier de base.30 10. Dispositif selon la revendication 9, dans lequel l'unité de traitement est en outre configurée pour substituer au moins un marqueur du fichier de base par une variable de test calculée. 11. Dispositif selon l'une des revendications 8 à 10, comportant le calcul d'au moins une variable de test parmi : - un nombre de processus à faire exécuter par l'infrastructure informatique, - une durée de démarrage de processus à faire exécuter par l'infrastructure informatique, - une durée de test, et - une durée d'itération d'un scénario de test durant le test. 12. Dispositif (11, 40) de mesure de performance d'infrastructure informatique (10), comportant une unité de traitement (42) pour lire un fichier d'injection généré selon l'une des revendications 1 à 4, envoyer au moins une requête du fichier d'injection (12) à destination de l'infrastructure informatique selon le fichier d'injection reçu, et pour mesurer une performance de l'infrastructure informatique en fonction de l'exécution de ladite au moins une requête par ladite infrastructure informatique. 13. Système de mesure de performance d'infrastructure informatique comportant : - un dispositif de génération de fichier d'injection selon l'une des revendications 8 à 11, et - un dispositif de mesure de performance selon la revendication 12.