web-dev-qa-db-fra.com

Test avec JMeter: comment exécuter N requêtes par seconde

J'ai besoin de tester si notre système peut exécuter N requêtes par seconde . Techniquement, il s'agit de 2 requêtes à une API, de 2 requêtes à une autre et de 6 requêtes à une troisième . Mais il est important qu'elles se produisent simultanément - donc 10 requêtes par seconde . Ainsi, dans JMeter, j'ai créé trois groupes de threads, définissant d'abord le nombre de threads 1 et le temps de montée en puissance de 0 . Le deuxième groupe de threads est identique, et le troisième groupe de threads définit le nombre de threads 6 et le temps de montée en puissance 0 . Mais cela ne garantit pas vraiment qu'il va les exécuter par seconde Comment puis-je imiter cela? Et comment puis-je voir les résultats - s'il était capable de performer ou non?

Merci! 

jmeterload-testingperformance-testingstress-testing
42
alexeypro

Comme avec tout test de réseau, il y aura toujours des problèmes, en particulier avec la latence - même si vous pouvez envoyer exactement 6 par seconde, ils seront envoyés de manière séquentielle (c'est ainsi que les paquets sont envoyés) et peuvent ne pas tous frappé dans cette seconde, plus le temps de traitement.

Généralement, lorsque les mesures de performances sont spécifiques à x par seconde, elles sont mesurées sur une période donnée. Votre API peut même avoir un tampon - vous pouvez donc techniquement envoyer 6 par seconde, mais en traiter 5 par seconde, avec un tampon de 20, ce qui signifie que le trafic serait bon pour 20 secondes de trafic, car vous en auriez envoyé 120, prendrait 120/5 = 24 secondes pour traiter. Mais pas plus que cela ne saturerait le tampon. Il est donc insuffisant d’envoyer exactement 6 à la seconde pour tester.

Dans le groupe de threads, vous avez raison de définir le nombre de threads (utilisateurs) sur 6. Puis lancez-le en boucle pour toujours (cochez-le ou placez-le dans une boucle while) et ajoutez un écouteur, tel que le rapport global et l'arborescence des résultats. Les résultats que vous pouvez utiliser pour vérifier les éléments pertinents sont envoyés et répondus (en supposant que vous validez les réponses) et dans le rapport global, vous pouvez voir le nombre de chaque activité qui se passe par heure (multipliez évidemment par 3600 pour secondes, mais en raison de cette imprécision, il est préférable de l’exécuter longtemps).

Le test de charge initial peut maintenant être exécuté et, en tant que test plus précis, vous pouvez le laisser fonctionner plus longtemps (test d'imprégnation) pour voir si d'autres problèmes se posent: débordement de la mémoire tampon, fuite de mémoire ou autres événements inattendus.

30
Mark Mayo

Vous pouvez utiliser ConstantThroughputTimer.

Citation de fichiers d'aide JMeter ci-dessous:

18.6.4 Minuterie à débit constant Ce temporisateur introduit des pauses variables, calculées pour maintenir le débit total (en nombre d’échantillons par minute) aussi proche que possible d’un chiffre donné. Bien entendu, le débit sera plus faible si le serveur n’est pas capable de le gérer, ou si d’autres timers ou éléments de test fastidieux l’empêchent de le faire . N.B. Bien que le minuteur soit appelé le minuteur à débit constant, la valeur du débit n'a pas besoin d'être constante. Il peut être défini en termes d'appel de variable ou de fonction et la valeur peut être modifiée au cours d'un test.

Par exemple, je l'ai utilisé pour générer 40 requêtes par seconde:

 <ConstantThroughputTimer guiclass="TestBeanGUI" testclass="ConstantThroughputTimer" testname="Constant Throughput Timer" enabled="true">
      <stringProp name="calcMode">all active threads in current thread group</stringProp>
      <doubleProp>
        <name>throughput</name>
        <value>2400.0</value>
        <savedValue>0.0</savedValue>
      </doubleProp>
    </ConstantThroughputTimer>

Et c'est un résumé:

Created the tree successfully using performance/search-performance.jmx
Starting the test @ Tue Mar 15 16:28:39 CET 2011 (1300202919244)
Waiting for possible shutdown message on port 4445
Generate Summary Results +  3247 in  80,3s =   40,4/s Avg:    18 Min:     0 Max:  1328 Err:   108 (3,33%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    15 Min:     1 Max:  2071 Err:   378 (5,25%)
Generate Summary Results = 10446 in 260,3s =   40,1/s Avg:    16 Min:     0 Max:  2071 Err:   486 (4,65%)
Generate Summary Results +  7200 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:   152 Err:   399 (5,54%)
Generate Summary Results = 17646 in 440,4s =   40,1/s Avg:    15 Min:     0 Max:  2071 Err:   885 (5,02%)
Generate Summary Results +  7199 in 180,0s =   40,0/s Avg:    14 Min:     0 Max:  1797 Err:   436 (6,06%)
Generate Summary Results = 24845 in 620,4s =   40,0/s Avg:    15 Min:     0 Max:  2071 Err:  1321 (5,32%)

Mais je lance ce test dans mon réseau.

58
lb_lb

Utiliser le Minuterie de façonnage du débit

16
Andrey Pokhilko

J'ai eu le même problème et voici deux solutions que j'ai trouvées:

Solution 1:
Vous pouvez utiliser le groupe de threads pas à pas (permet de définir les étapes d’augmentation du nombre de threads sur des périodes de temps définies) avec une minuterie à débit constant. Throughput Timer vous permet de définir le nombre d’échantillons que le thread peut envoyer par minute (par exemple, si vous le définissez sur 1, le thread n’enverra qu’une demande par minute). Vous pouvez également appliquer le minuteur de débit à tous les threads de votre groupe de threads ou avoir un minuteur pour chaque thread avec ses propres paramètres . Pour en savoir plus sur le minuteur de débit, cliquez ici: https://www.blazemeter.com/blog/how -use-jmeters-débit-constant-timer

Solution 2:
Utilisez "SetUp Thread Group". Vous pouvez calculer le nombre de threads et le temps nécessaire pour obtenir le nombre de threads par seconde souhaité.

1
Yury Ustsinchyk

Vous pouvez utiliser Fonction de planification de retour et aurez également besoin d'un groupe de threads d'accès simultané. 

0
raman rayat