Modifier le nombre de threads du plan de test dans JMeter, au moment de l’exécution

La réponse courte est: non, vous ne pouvez pas modifier le nombre de threads de manière dynamic pendant l’exécution. Chaque valeur du nombre d’unités d’exécution n’est lue qu’une fois lorsque le plan de test est compilé pour la première fois et n’est plus résolue après ce point; elle rest donc fixe.

IMHO, c’est juste une fonctionnalité sophistiquée qui n’a aucun avantage réel à faire des tests de performances appropriés. Pour générer un rapport de test pertinent, vous devez avoir une répétabilité , une méthodologie de test et des scénarios clairement définis. Afin de comparer l’impact de tout changement d’application, de serveur ou d’infrastructure, vous avez besoin de répétabilité.

Que veux-tu dire par

Nous ne pouvons pas prédire l’utilisateur de notre site

C’est pourquoi nous effectuons des tests de performance en premier lieu. Pour savoir quelle est la limite de notre application / infrastructure.
Par exemple, la mesure la plus importante que vous pouvez produire est la manière dont le temps de réponse de votre application change lorsque le nombre d’utilisateurs parallèles change. Mais ne changez pas de façon erratique, au moment de l’exécution.

Avec le groupe de threads Ultimate des plugins jMeter, vous pouvez couvrir n’importe quel scénario imaginable.

Cette fonctionnalité est en effet utile et étonnamment difficile à mettre en œuvre, même avec des outils commerciaux tels que Loadrunner. Je comparerais cela à la recherche du volume maximal des haut-parleurs. Vous pouvez manuellement augmenter le volume jusqu’à ce qu’il commence à craquer, puis le baisser légèrement pour maintenir ce volume maximum. De la même manière, pour rechercher la capacité de pointe d’une application, vous souhaitez que le contrôle «augmente le volume» jusqu’à ce que des erreurs soient détectées, puis réglez-le légèrement pour voir s’il se stabilise. Vous pouvez ensuite maintenir cette charge pour localiser le goulot d’étranglement.

Quoi qu’il en soit, pour répondre à la question, ce que j’ai fait dans le passé est d’utiliser une influence externe, telle qu’un nom de fichier ou similaire. Ensuite, combinez cela avec la référence unique de thread, vous pouvez contrôler les threads exécutés et ceux qui sont maintenus (en pause ou similaire).

Par exemple, si vous commencez avec 100 threads, puis créez un fichier appelé “5.txt” à un emplacement spécifique, vous pouvez append du code de sorte que si les threads voient que leur propre référence est égale ou inférieure au nombre, ils peuvent courir. Sinon, il tombe en pause. Au début de cet exemple, 5 threads s’exécutent et 95 s’interrompent. Vous pouvez alors renommer le fichier en ’25 .txt ‘, et les threads 6 à 25 commenceraient à s’exécuter. Cela fonctionnerait également dans l’autre sens, le changer en ’20 .txt ‘signifierait que les threads 21-25 seraient à nouveau mis en pause.

La clé est de démarrer suffisamment de threads pour dépasser votre pic attendu.

vous pouvez le changer en fonction d’une variable que vous avez définie dans un thread de démarrage. Voir ci-dessous.

Dans Jmeter, comment définir un nombre variable de threads à l’aide d’une variable d’échantillonnage beanshell?

Cependant, une fois que le groupe de threads a démarré, vous ne pouvez plus le modifier. Pour le gars qui a dit cette fonctionnalité ne serait pas utile, je ne suis pas d’accord. Il existe de nombreux types de tests de charge et ils n’ont pas tous le même nombre d’utilisateurs en cours d’exécution pour la durée. Voici juste 2 exemples de tests de charge d’entreprise que nous menons à la banque où je travaille:

• test de durée – le même nombre d’utilisateurs s’exécutent pendant toute la durée (éventuellement avec une courte période de montée en puissance)
• Test du sharepoint rupture – augmentez progressivement le nombre d’utilisateurs jusqu’à ce que l’application se casse
• Spike test – exécuté avec un nombre constant d’utilisateurs mais de manière sporadique
  jeter dans un grand nombre d’utilisateurs

Un test de point d’arrêt augmente le nombre d’utilisateurs jusqu’à la fermeture de l’application (l’objective étant de voir à quelle hauteur votre application peut évoluer). Vous pouvez en quelque sorte le faire en utilisant la propriété “ramp up period” des groupes de threads. Si vous définissez le temps de montée en puissance sur 1000 et le nombre de threads sur 100, un thread sera ajouté toutes les 10 secondes.

Les tests Spike ressemblent aux tests de durée, mais un grand nombre d’utilisateurs se connectent à certains intervalles. Ceci est utilisé pour jauger le temps de réponse des applications pendant les heures pleines scénario réel).

Jmeter ne gère pas tous les scénarios de test de charge nécessaires aux tests de charge en entreprise. Un des travaux autour de Im consiste à démarrer tous les threads, mais à trouver un moyen de les faire dormir. Vous pouvez donc définir le nombre de threads sur 1000 mais en faire en sorte que 980 d’entre eux dorment ou ne fassent rien. Alors peut-être que quand time_in_seconds% 5 == 0 (toutes les 5 minutes) vous autorisez les autres threads à s’exécuter – simulant un test de pics. L’idée est que vous pouvez coder en dur les threads jusqu’à 1000 et que vous aurez toujours 1000 threads en cours d’exécution – mais ils ne doivent pas tous faire quelque chose à tout moment.

(en d’autres termes, vous pouvez probablement trouver un moyen mais vous devez faire preuve de créativité)

Mise à jour: Je viens de trouver ce plugin qui permet différents types de tests. Je n’ai pas encore essayé, mais cela semble prometteur: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

Vous pouvez définir / modifier le nombre de threads à l’exécution à l’aide de l’option de ligne de commande …

vous pouvez utiliser des appels de fonction ou des références de variable aux parameters utilisateur (qui peuvent être des fonctions), ou des références de variable à des variables définies par des fonctions précédemment dans le test. Il y a plus d’une façon de le faire.

Supposons que vous souhaitiez pouvoir modifier le nombre de threads dans un plan de test. Choisissez un nom de propriété approprié, par exemple group1.threads. Remplacez le nombre de threads dans l’interface graphique (ou le JMX, si vous vous sentez courageux!) Par l’appel de fonction suivant:

Veuillez définir la propriété ci-dessous dans le groupe de thread JMeter comme suit: $ {__ property (group1.threads)}

Ensuite, lorsque vous démarrez JMeter, définissez la propriété sur la ligne de commande:

jmeter -Jgroup1.threads = 10

Nous ne pouvons pas prédire l’utilisateur de notre site.

Sûr que vous pouvez. C’est à quoi servent les journaux HTTP de votre site existant. Vous pouvez également utiliser les journaux d’outils tels que Omniture ou vos journaux CDN. Si vous examinez la combinaison des adresses IP de l’utilisateur réel, de la demande et du référent dans les journaux, vous pourrez créer une carte transversale de chaque utilisateur sur votre site. Vous serez en mesure de profiler les pages de nœuds feuille uniques de nombre élevé de hits d’un processus métier donné pour comprendre le nombre de fois qu’un processus métier donné se passe en une heure. Vous pourrez examiner l’abandon en jetant un coup d’œil à l’entonnoir dans des outils tels que Omniture. Si vous avez besoin d’outils pour cette parsing, je vous recommande Splunk. C’est facile à installer et à configurer. Le temps de valorisation est très rapide.

Plus vous avez de données de journal que vous utilisez pour établir le profil, plus vous pouvez vous rapprocher de ce que les utilisateurs font au cours d’une journée / semaine / mois / vente au comptant / fin de sortingmestre / fin d’année / etc …. Vous devez combinez les résultats réels à un moment donné avec les résultats réels des moments antérieurs à la croissance du projet dans le temps, car vous devrez tenir compte de la croissance de votre modèle de test de performance.

Si vous n’obtenez pas les bonnes valeurs, alors la valeur de votre test en tant que prédicteur de ce qui va / pourra se passer en production sera assez faible. Ce n’est pas un échec d’un outil donné, mais un échec du processus de planification pour le modèle de charge réel utilisé dans le cadre des exigences de test. Si vous ne pouvez pas construire ces modèles, vous devez attirer quelqu’un dans votre équipe qui le peut.

Cette capacité à produire un modèle de charge valide, indépendamment de l’outil, constitue la différence entre les tests réduisant le risque et la charge de projection.

En activant le serveur BeanShell, vous pouvez modifier les propriétés lors de l’exécution. Activez-le et mettez telnet sur le port 9001 (avertissement: pas sécurisé!) D’après un test que j’ai effectué, malheureusement, il semble que le nombre de threads n’est pas appliqué au moment de l’exécution. Cependant, vous pouvez toujours manipuler la charge du test par d’autres moyens, par exemple, appliquer une timer de débit coûteuse paramétrée avec une propriété nommée “débit” et la modifier au moment de l’exécution de la manière suivante:

setprop("throughput","2000"); 

C’est bien expliqué dans le guide.