Vous effectuez un test de résistance sur une application Web?

Dans le passé, j'utilisais Microsoft Web Application Stress Tool et Pylot pour tester les applications Web sous contrainte. J'avais écrit une page d'accueil simple, un script de connexion et une visite guidée du site (dans un site de commerce électronique en ajoutant quelques articles à un panier et à la caisse).

Le simple fait de frapper fort la page d'accueil avec une poignée de développeurs localiserait presque toujours un problème majeur. Plus de problèmes d'évolutivité surgiraient à la deuxième étape, et encore plus - après le lancement.

L'URL des outils que j'ai utilisés était Microsoft Homer (alias Microsoft Web Application Stress Tool ) et Pylot .

Les rapports générés par ces outils n'ont jamais eu beaucoup de sens pour moi, et je passais de nombreuses heures à essayer de déterminer le type de charge simultanée que le site pourrait prendre en charge. Cela en valait toujours la peine car les bugs et les goulots d'étranglement les plus stupides se produisaient toujours (par exemple, les erreurs de configuration du serveur Web).

Qu'avez-vous fait, quels outils avez-vous utilisés et quel succès avez-vous eu avec votre approche? La partie la plus intéressante pour moi est de trouver une sorte de formule significative pour calculer le nombre d'utilisateurs simultanés qu'une application peut prendre en charge à partir des chiffres rapportés par l'application de test de stress.

Voici un autre vote pour JMeter .

JMeter est un outil de test de charge open-source, écrit en Java. Il est capable de tester un certain nombre de types de serveurs différents (par exemple, le Web, les services Web, la base de données, à peu près tout ce qui utilise les demandes essentiellement).

Il a cependant une courbe d'apprentissage abrupte une fois que vous commencez à passer à des tests compliqués, mais cela en vaut la peine. Vous pouvez être opérationnel très rapidement, et selon le type de test de stress que vous souhaitez faire, cela pourrait être bien.

Avantages:

• Outil Open-Source / gratuit du projet Apache (aide au buy-in)
• Facile à démarrer et facile à utiliser une fois que vous maîtrisez les concepts de base. (C'est-à-dire, comment créer une demande, comment créer une assertion, comment travailler avec des variables, etc.).
• Très évolutif. J'ai effectué des tests avec 11 machines générant une charge sur le serveur de près d'un million de hits / heure. C'était beaucoup plus facile à installer que ce à quoi je m'attendais.
• A une communauté active et de bonnes ressources pour vous aider à être opérationnel. Lisez d'abord les tutoriels et jouez avec pendant un moment.

Les inconvénients:

• L'interface utilisateur est écrite en Swing. (Pouah!)
• JMeter fonctionne en analysant le texte de réponse renvoyé par le serveur. Donc, si vous cherchez à valider toute sorte de comportements javascript, vous n'avez pas de chance.
• La courbe d'apprentissage est abrupte pour les non-programmeurs. Si vous connaissez les expressions régulières, vous êtes déjà en avance sur le jeu.
• Il y a un grand nombre d' idiots ( insérer des mots explicatifs ) dans le forum de support qui posent des questions stupides qui pourraient être facilement résolues s'ils donnaient un coup d'œil rapide à la documentation. («Comment utiliser JMeter pour tester la résistance de mon interface graphique Windows» apparaît assez fréquemment).
• Le fait de déclarer «prêt à l'emploi» laisse beaucoup à désirer, en particulier pour les tests plus importants. Dans le test que j'ai mentionné ci-dessus, j'ai fini par devoir écrire une application de console rapide pour effectuer certaines des conversions 'xml-logfile' en 'html'. C'était il y a quelques années, il est donc probable que cela ne serait plus nécessaire.

J'ai utilisé The Grinder . C'est open source, assez facile à utiliser et très configurable. Il est basé sur Java et utilise Jython pour les scripts. Nous l'avons exécuté sur une application Web .NET, alors ne pensez pas qu'il s'agit d'un outil uniquement Java (par nature, tout outil de stress Web ne doit pas être lié à la plate-forme qu'il utilise).

Nous avons fait des trucs sympas avec elle ... nous étions une application de télécommunications basée sur le Web, donc une utilisation intéressante que j'ai mise en place était d'imiter la composition d'un numéro via notre application Web, puis j'ai utilisé un outil de réponse automatique que nous avions (qui était essentiellement un tutoriel application de Microsoft pour se connecter à leur serveur RTC LCS ... qui est ce à quoi Microsoft Office Communicator se connecte sur un réseau local ... puis modifié pour simplement prendre les appels automatiquement). Cela nous a ensuite permis d'utiliser ceci au lieu d'un outil de téléphonie coûteux appelé The Hammer (ou quelque chose comme ça).

Quoi qu'il en soit, nous avons également utilisé l'outil pour voir comment notre application a résisté à une charge élevée, et il a été très efficace pour trouver des goulots d'étranglement. L'outil a intégré des rapports pour montrer combien de temps les demandes prennent, mais nous ne l'avons jamais utilisé. Les journaux peuvent également stocker toutes les réponses et ainsi de suite, ou la journalisation personnalisée.

Je recommande fortement cet outil, très utile pour le prix ... mais attendez-vous à faire une configuration personnalisée avec lui (il a un proxy intégré pour enregistrer un script, mais il peut avoir besoin de personnalisation pour capturer quelque chose comme des sessions ... Je sais J'ai dû le personnaliser pour utiliser une session unique par thread).

Un peu tard pour cette soirée. Je suis d'accord que Pylot est le meilleur outil open source à venir. Il est simple à utiliser et est activement travaillé par un bon gars ( Corey Goldberg ). En tant que fondateur d' OpenQA , je suis également heureux que Pylot soit maintenant répertorié sur notre page d'accueil et utilise une partie de notre infrastructure (à savoir les forums).

Cependant, j'ai également récemment décidé que le concept entier de test de charge était imparfait: l'émulation du trafic HTTP, avec des applications aussi complexes qu'elles sont devenues, est une douleur dans le cul. C'est pourquoi j'ai créé l'outil commercial BrowserMob. Il s'agit d'un service de test de charge externe qui utilise Selenium pour contrôler de vrais navigateurs Web lors de la lecture de la charge.

L'approche nécessite évidemment une tonne de matériel de plus que les techniques de test de charge normales, mais le matériel est en fait assez bon marché lorsque vous utilisez le cloud computing. Et un bel effet secondaire de cela est que le script est beaucoup plus facile que le test de charge normal. Vous n'avez pas à faire de correspondance regex avancée (comme JMeter l'exige) pour extraire les cookies, l'état de session .NET, les paramètres de demande Ajax, etc. Puisque vous utilisez de vrais navigateurs, ils font juste ce qu'ils sont censés faire.

Désolé de lancer un produit commercial de manière flagrante, mais j'espère que le concept est intéressant pour certaines personnes et au moins les amène à réfléchir à de nouvelles façons de gérer les tests de charge lorsque vous avez accès à un tas de matériel supplémentaire!

J'ai utilisé JMeter . En plus de tester le serveur Web, vous pouvez également tester votre backend de base de données, vos services de messagerie et vos serveurs de messagerie.

ab , siège , Tsung , httperf , Piétinement , Pylot, demande-log-analyseur , perftools

Pour une utilisation simple, je perfer ab (benchmark apache) et siège, plus tard est nécessaire car ab ne prend pas en charge les cookies et créerait des sessions sans fin à partir du site dynamique.

les deux sont simples à démarrer:

ab -c n -t 30 url

siege -b -c n -t 30s url

le siège peut s'exécuter avec plus d'URL.

la dernière version de siège devient verbeuse dans siegerc, ce qui est ennuyeux. vous ne pouvez le désactiver qu'en modifiant ce fichier ( /usr/local/etc/siegerc).

Pour un service Web, consultez loader.io .

Résumé:

loader.io est un service de test de charge gratuit qui vous permet de tester vos applications Web / API avec des milliers de connexions simultanées.

Ils ont également une API .

Comme cette question est toujours ouverte, je ferais aussi bien de peser.

La bonne nouvelle est qu'au cours des 5 dernières années, les outils Open Source ont vraiment mûri et décollé dans l'espace, la mauvaise nouvelle est qu'il y en a tellement.

Voici mes pensées: -

Jmeter vs Grinder

Jmeter est basé sur une spécification de style XML, qui est construite via une interface graphique.

Grinder utilise des scripts Jython dans un framework Java multi-thread, donc plus orienté vers les programmeurs.

Les deux outils géreront HTTP et HTTPS et auront un enregistreur proxy pour vous aider à démarrer. Les deux outils utilisent le modèle Controller pour piloter plusieurs agents de test, de sorte que l'évolutivité n'est pas un problème (étant donné l'accès au Cloud).

Ce qui est mieux:-

Un appel difficile car la courbe d'apprentissage est abrupte avec les deux outils lorsque vous entrez dans les exigences de script plus complexes pour la réécriture d'URL, la corrélation, la fourniture de données uniques par utilisateur virtuel et la simulation de la première fois ou des utilisateurs de retour (en manipulant les en-têtes HTTP).

Cela dit, je commencerais par Jmeter car cet outil a un énorme succès et il existe de nombreux exemples et tutoriels sur le Web pour utiliser cet outil. Si et quand vous arrivez à un «barrage routier», c'est quelque chose que vous ne pouvez pas «facilement» faire avec Jmeter, alors jetez un œil au Grinder. La bonne nouvelle est que ces deux outils ont la même exigence Java et qu'une solution «mix and match» n'est pas hors de question.

Une nouveauté à ajouter: les navigateurs sans tête exécutant plusieurs instances de Selenium WebDriver.

Il s'agit d'une approche relativement nouvelle, car elle repose sur la disponibilité de ressources qui peuvent désormais être provisionnées à partir du cloud. Avec cette approche, un script Selenium (WebDriver) est pris et exécuté dans un pilote de navigateur sans tête (c'est-à-dire WebDriver = New HtmlUnitDriver ()) dans plusieurs threads.

D'après l'expérience, environ 25 instances de `` navigateurs sans tête '' peuvent être exécutées à partir d'Amazon M1 Small Instance.

Cela signifie que tous les problèmes de corrélation et de réécriture d'URL disparaissent lorsque vous réutilisez vos scripts de test fonctionnel pour devenir des scripts de test de performances.

L'évolutivité est compromise car plus de machines virtuelles seront nécessaires pour piloter la charge, par rapport à un pilote HTTP tel que Grinder ou Jmeter. Cela dit, si vous cherchez à conduire 500 utilisateurs virtuels, alors avec 20 petites instances Amazon (6 cents de l'heure chacune) à un coût de seulement 1,20 $ par heure, vous obtenez une charge très proche de l'expérience utilisateur réelle.

En outre, il y a une super open-source pure python distribuée et échelonnable acridienne cadre qui utilise greenlets . Il est excellent pour simuler une énorme quantité d'utilisateurs simultanés.

Nous avons récemment commencé à utiliser Gatling pour les tests de charge. Je recommande fortement d'essayer cet outil pour les tests de charge. Nous avions utilisé SOASTA et JMETER dans le passé. Notre principale raison de considérer Gatling est la suivante:

• Enregistreur pour enregistrer le scénario
• Utiliser Akka et Netty qui donne de meilleures performances par rapport au modèle Jmeter Threading
• DSL Scala qui est très maintenable par rapport à Jmeter XML
• Facile à écrire les tests, ne faites pas peur si c'est scala.
• Rapports

Permettez-moi de vous donner un exemple simple pour écrire le code à l'aide de Gatling Code:

// your code starts here  
val scn = scenario("Scenario")  
     .exec(http("Page")
     .get("http://example.com")) 
// injecting 100 user enter code here's on above scenario.   
setUp(scn.inject(atOnceUsers(100)))       

Cependant, vous pouvez le rendre aussi compliqué que possible. L'une des fonctionnalités qui se démarquent pour Gatling est le rapport qui est très détaillé.

Voici quelques liens:
Gatling
Gatling Tutorial

J'ai récemment donné une conférence à ce sujet, vous pouvez suivre cette conférence ici:
https://docs.google.com/viewer?url=http%3A%2F%2Ffiles.meetup.com%2F3872152%2FExploring-Load-Testing-with -Gatling.pdf

C'est une vieille question, mais je pense que les nouvelles solutions méritent d'être mentionnées. Checkout LoadImpact: http://www.loadimpact.com .

J'ai essayé WebLoad, c'est un outil assez soigné. Il est livré avec un script de test IDE qui vous permet d'enregistrer l'action de l'utilisateur sur un site Web. Il dessine également un graphique lors de l'exécution d'un test de stress sur votre serveur Web. Essayez-le, je le recommande vivement.

En essayant tous les éléments mentionnés ici, j'ai trouvé le curl-loader le mieux adapté à mes besoins. interface très simple, surveillance en temps réel, statistiques utiles, à partir desquelles je construis des graphiques de performances. Toutes les fonctionnalités de libcurl sont incluses.

Blaze mètre a une extension chrome pour enregistrer des sessions et les exporter vers JMeter (nécessite actuellement une connexion). Vous avez également la possibilité de leur verser de l'argent pour l'exécuter sur leur cluster de serveurs JMeter (leur prix semble bien meilleur que LoadImpact que je viens d'arrêter d'utiliser):

• Extension Chrome BlazeMeter
• Entrée de blog à ce sujet

Je n'ai aucune association avec eux, j'aime juste l'apparence de leur service, même si je n'ai pas encore utilisé la version payante.

Vous avez posé cette question il y a presque un an et je ne sais pas si vous cherchez toujours une autre façon de comparer votre site Web. Cependant, comme cette question n'est toujours pas marquée comme résolue, je voudrais suggérer le service Web gratuit LoadImpact (en fait non affilié). Je viens de recevoir ce lien via Twitter et je voudrais partager cette découverte. Ils créent un bon aperçu raisonnable et pour quelques dollars de plus, vous obtenez le "mode d'impact complet". Cela semble probablement étrange, mais bonne chance pour pousser et freiner votre service :)

J'ai trouvé IBM Page Detailer également un outil intéressant avec lequel travailler.

J'ai utilisé openSTA .

Cela permet d'enregistrer une session avec un site Web, puis de la lire via un langage de script relativement simple.

Vous pouvez facilement tester les services Web et écrire vos propres scripts.

Il vous permet de rassembler les scripts dans un test comme vous le souhaitez et de configurer le nombre d'itérations, le nombre d'utilisateurs à chaque itération, le temps de montée en puissance pour introduire chaque nouvel utilisateur et le délai entre chaque itération. Des tests peuvent également être programmés à l'avenir.

C'est open source et gratuit.

Il produit un certain nombre de rapports qui peuvent être enregistrés dans une feuille de calcul. Nous utilisons ensuite un tableau croisé dynamique pour analyser et représenter facilement les résultats.

Nous utilisons l'outil Microsoft mentionné - Microsoft Web Application Stress Tool. C'est l'outil le plus simple que j'ai utilisé. Il est limité à bien des égards, notamment en ne pouvant atteindre le port 80 que lors des tests créés manuellement. Mais, sa facilité d'utilisation signifie qu'il est réellement utilisé.

Nous complétons la charge de cet outil avec d'autres outils, notamment OpenSTA et les araignées de vérification des liens.

JMeter semble bon d'après mon évaluation initiale, j'espère l'inclure dans notre intégration continue à l'avenir. Mais, JMeter est complexe et non trivial à déployer.

Je suggère d'ouvrir une autre question concernant l'interprétation des résultats de l'outil de stress MS.

Visual Studio Test Edition 2010 (2008 bien aussi). C'est un outil vraiment simple et puissant pour créer des tests web / charge avec.

Le bonus de cet outil lors de l'utilisation contre des serveurs Windows est que vous obtenez un accès intégré à toutes les statistiques du serveur perfmon dans votre rapport. Vraiment utile.

L'autre bonus est qu'avec le projet Visual Studio vous pouvez intégrer une "Session Performance" qui profilera l'exécution du code de votre site web.

Si vous servez des pages Web à partir d'un serveur Windows, c'est le meilleur outil disponible.

Cependant, une licence distincte et coûteuse est requise pour utiliser plusieurs machines pour tester l'application.

Nous avons développé un processus qui traite la mesure de la charge et des performances comme une préoccupation de premier ordre - comme vous le dites, le laisser à la fin du projet a tendance à décevoir ...

Ainsi, pendant le développement, nous incluons des tests multi-utilisateurs très basiques (utilisant du sélénium), qui vérifient la folie de base comme la gestion de session interrompue, les problèmes de concurrence évidents et les problèmes évidents de contention de ressources. Les projets non triviaux incluent cela dans le processus d'intégration continue, nous recevons donc des retours très réguliers.

Pour les projets qui n'ont pas d'exigences de performances extrêmes, nous incluons des tests de performances de base dans nos tests; généralement, nous écrivons les tests à l'aide de BadBoy et les importons dans JMeter, en remplaçant les informations de connexion et d'autres éléments spécifiques au thread. Nous les augmentons ensuite au niveau où le serveur traite 100 requêtes par seconde; si le temps de réponse est inférieur à 1 seconde, cela suffit généralement. Nous lançons et continuons notre vie.

Pour les projets avec des exigences de performances extrêmes, nous utilisons toujours BadBoy et JMeter, mais consacrons beaucoup d'énergie à la compréhension des goulots d'étranglement sur les serveurs de notre banc d'essai (serveurs Web et de base de données, généralement). Il existe un bon outil pour analyser les journaux d'événements Microsoft qui aide beaucoup à cela. Nous trouvons généralement des goulots d'étranglement inattendus, que nous optimisons si possible; cela nous donne une application aussi rapide que possible sur "1 serveur web, 1 serveur de base de données". Nous déployons ensuite généralement sur notre infrastructure cible et utilisons l'un des services «Jmeter in the cloud» pour relancer les tests à grande échelle.

Encore une fois, les rapports PAL aident à analyser ce qui s'est passé pendant les tests - vous voyez souvent des goulots d'étranglement très différents sur les environnements de production.

L'essentiel est de s'assurer que vous n'exécutez pas seulement vos tests de stress, mais aussi que vous collectez les informations dont vous avez besoin pour comprendre les performances de votre application.

Il y a beaucoup de bons outils mentionnés ici. Je me demande si les outils sont une réponse à la question: "Comment testez-vous le stress d'une application web?" Les outils ne fournissent pas vraiment de méthode pour souligner une application Web. Voici ce que je sais:

Les tests de résistance montrent comment une application Web échoue tout en fournissant des réponses à une population croissante d'utilisateurs. Les tests de résistance montrent comment l'application Web fonctionne en cas d'échec. Aujourd'hui, la plupart des applications Web - en particulier les applications Web sociales / mobiles - sont des intégrations de services. Par exemple, lorsque Facebook a été déconnecté en mai 2011, vous ne pouviez pas vous connecter à l'application Web de Pepsi.com. L'application n'a pas échoué complètement, seule une grande partie de sa fonction normale n'est plus disponible pour les utilisateurs.

Les tests de performances montrent la capacité d'une application Web à maintenir les temps de réponse indépendamment du nombre d'utilisateurs qui utilisent l'application simultanément. Par exemple, une application qui gère 10 transactions par seconde avec 10 utilisateurs simultanés doit gérer 20 transactions par seconde pour 20 utilisateurs. Si l'application gère moins de 20 transactions par seconde, les temps de réponse s'allongent et l'application n'est pas en mesure d'atteindre une évolutivité linéaire.

De plus, dans l'exemple ci-dessus, le nombre de transactions par seconde ne doit concerner que les opérations réussies d'un cas d'utilisation / workflow de test. Les échecs se produisent généralement dans des délais plus courts et rendront la mesure TPS trop optimiste. Les échecs sont importants pour un test de stress et de performances car ils génèrent également une charge sur l'application.

J'ai rédigé la méthodologie PushToTest dans le Guide de l'utilisateur TestMaker sur http://www.pushtotest.com/pushtotest-testmaker-6-methodology . TestMaker est disponible en deux versions: la version communautaire Open Source (GPL) et TestMaker Enterprise (commercial avec un excellent support professionnel).

-Franc

Jetez un œil à LoadBooster ( https://www.loadbooster.com ). Il utilise un navigateur scriptable sans tête PhantomJS / CasperJs pour tester les sites Web. Phantomjs analysera et rendra chaque page, exécutera le script côté client. L'approche du navigateur sans tête est plus facile à écrire des scénarios de test pour prendre en charge l'application AJAX lourde Web 2.0 complexe, la navigation dans le navigateur, le clic de souris et les frappes dans le navigateur ou attendre jusqu'à ce qu'un élément existe dans DOM. LoadBooster prend également en charge le script HTML sélénium.

Avertissement: je travaille pour LoadBooster.

Essayez ZebraTester ce qui est beaucoup plus facile à utiliser que jMeter. J'utilise jMeter depuis longtemps, mais le temps de configuration total pour un test de charge a toujours été un problème. Bien que ZebraTester ne soit pas open source, le temps que j'ai économisé au cours des six derniers mois le compense. Ils ont également un portail SaaS qui peut être utilisé pour exécuter rapidement des tests à l'aide de leurs générateurs de charge.

Encore une remarque, pour notre application Web, j'ai constaté que nous avions d'énormes problèmes de performances en raison de conflits entre les threads sur les verrous ... donc la morale était de réfléchir très attentivement au schéma de verrouillage. Nous avons fini par avoir des threads de travail pour limiter trop de demandes à l'aide d'un gestionnaire http asynchrone, sinon l'application serait simplement submergée et planterait et graverait. Cela signifiait qu'un énorme arriéré pouvait s'accumuler, mais au moins le site resterait en place.

Jetez un œil à TestComplete .

J'appuie la suggestion d'Opensta. J'ajouterais simplement que cela vous permet de faire des choses pour surveiller le serveur que vous testez en utilisant SMTP. Nous gardons la trace de la charge du processeur, de la mémoire utilisée, des byes envoyés, etc. La version de la source est plus délicate qu'avec la plupart des logiciels libres.

J'ai joué avec JMeter. On pense qu'il n'a pas pu tester était ASP.NET Webforms. Le viewstate a cassé mes tests. Je ne sais pas pourquoi, mais il y a quelques outils qui ne gèrent pas bien l'état de vue. Mon projet actuel est ASP.NET MVC et JMeter fonctionne bien avec lui.

J'ai eu de bons résultats avec FunkLoad :

• interaction utilisateur facile à écrire
• les rapports sont clairs
• peut surveiller la charge du serveur

Au risque d'être accusé d'auto-promotion éhontée, je voudrais souligner que dans ma quête d'un outil de test de charge gratuit, je suis allé à cet article: http://www.devcurry.com/2010/07/10-free- tools-to-loadstress-test-your.html

Soit je n'ai pas pu obtenir le débit que je voulais, soit je n'ai pas pu obtenir la flexibilité que je voulais. ET je voulais agréger facilement les résultats de plusieurs hôtes de génération de test de charge dans l'analyse post-test.

J'ai essayé tous les outils de la liste et, à ma frustration, j'ai constaté qu'aucun d'entre eux ne faisait exactement ce que je voulais être en mesure de faire. J'en ai donc construit un et je le partage.

C'est ici: http://sourceforge.net/projects/loadmonger

PS: Aucun commentaire sarcastique sur le nom de gens qui connaissent l'argot urbain. Je n'étais pas mais je suis un peu plus mondain maintenant.

Je vote aussi pour jMeter et je veux ajouter quelques citations à la réponse @PeterBernier.

La question principale à laquelle répond le test de charge est le nombre d'utilisateurs simultanés que mon application Web peut prendre en charge? Afin d'obtenir une réponse correcte, les tests de charge doivent représenter l'utilisation réelle de l'application, aussi près que possible .

Gardez à l'esprit que jMeter a de nombreux éléments constitutifs: contrôleurs logiques , éléments de configuration , pré-processeurs , écouteurs , ... qui peuvent vous aider à cet égard .

Vous pouvez imiter la situation du monde réel avec jMeter, par exemple, vous pouvez:

1. Configurer jMeter pour agir en tant que navigateur réel par la configuration ( concurrent resource download, browser cache, http headers, setting request time out, cookie management, https support, encoding,ajax support , ...)
2. Configurer jMeter pour générer les demandes des utilisateurs (en définissant number of users per second, ramp-up time, scheduling, ...)
3. Configurez beaucoup de clients avec jMeter sur eux, pour faire un test de charge répartie.
4. Traitez la réponse pour savoir si le serveur répond correctement pendant le test. (Par exemple, assertréponse pour y trouver un texte)

Veuillez considérer:

• Il est facile de démarrer un véritable test d'application Web avec jMeter en quelques minutes. Le jMeter dispose d'un outil très simple qui enregistre votre scénario de test (connu sous le nom HTTP(S) Test Script Recorder).
• jMeter a beaucoup de plugins sur http://jmeter-plugins.org .
• L'interface utilisateur de jMeter est basée sur le swing et a apporté de bons changements dans jMeter 3.2. D'un autre côté, veuillez considérer que l'interface graphique JMeter ne doit être utilisée que pour le test et le débogage. Il n'est pas recommandé de l'utiliser en mode GUI pour un test réel. https://www.blazemeter.com/blog/5-ways-launch-jmeter-test-without-using-jmeter-gui . Configurez et testez votre scénario et exécutez-le en mode non-gui.
• Il existe de nombreux rapports montrant des outils dans jMeter (connu sous le nom listeners), mais ils ne sont pas censés être activés pendant le test. Vous devez exécuter votre test et générer des rapports ( .jtlfichiers). Ensuite, vous devez utiliser ces outils pour analyser le résultat. Veuillez consulter https://www.blazemeter.com/blog/jmeter-listeners-part-1-basic-display-formats ou https://www.tutorialspoint.com/jmeter/jmeter_listeners.htm .

Le https://www.blazemeter.com/jmeter contient de très bonnes informations pratiques pour vous aider à configurer votre environnement de test.