Can a jmeter test plan(JMX) with multiple thread groups have same name for all the thread groups and samplers inside??
What's the downside if we use this way
Yes, different thread groups with the same name may exist in a JMeter test plan. There is no technological barrier stopping this. When evaluating the test plan or examining the test results, it could become more challenging to recognize and differentiate distinct thread groups if there are several ones with the same name. Additionally, it can be more perplexing for other individuals who might be utilizing the test plan.
The test plan can be made more logically and simply by using distinct names for thread groups and samplers. Additional information, like as descriptions or comments, may be beneficial in order to provide more context and make the purpose of each thread group and sampler more clear.
There are no limitations when it comes to naming Thread Groups or Samplers, you can use the same label everywhere.
If needed you can trace down the problematic or failed SampleResult to this or that Sampler by looking at threadName column of the .jtl results file.
The only potentially dangerous limitation I can think of is properly naming Transaction Controller's children as if it will differ from the transaction Controler's name followed by dash followed by zero-based index of the Sampler - JMeter will fail to properly calculate the throughput and you will be seeing extra sample results in i.e. HTML Reporting Dashboard
Related
In J meter, I am unable pass property from thread 1 to thread 2 if there is JDBC request in thread 1. If there is no JDBC request, property is getting passed from thread 1 to thread 2. Any specific reason for this, Any changes i need to do? kindly help me on this.
Passing values between Thread Groups is not something you should be normally doing, I would recommend reconsidering the design of your JMeter script so it would not be required
There are several ways of passing values between different thread groups starting from using __setProperty() and __P() functions combination, using interim CSV files, and ending up with Inter-Thread Communication Plugin, they all should work irrespective of presence/absence of the JDBC test elements in this or that Thread Group
When anything goes wrong in the absolute majority of cases JMeter will print something to jmeter.log file, first of all check it for any warnings/errors and if they are not there - check the variables/properties values using Debug Sampler
I record and run the Jmeter script by keeping number of users = 1, in tread group.
Results tree output:
I increased the number of users to 3 and result tree output order changed.
Therefore my some of regular expression exacter logics get failed and resultant responses failed. How can I avoid this situation.
Is there way to manage result tree execution order.
If your regular expressions are under the requests and not at the same level as of HTTP requests then it should not be a problem.Every thread/vUser will run independently. But, in view results you will see request as and when executed by different threads and not in sequence.
As per JMeter Functions and Variables user manual chapter:
Variables are local to a thread
Each JMeter thread (virtual user) executes Samplers upside down (or according to the Logic Controllers). JMeter threads are absolutely independent from each other and each thread has its own variables.
So the problem must be somewhere else, inspect the state of the variables using Debug Sampler and the response data for /oauth calls - it might simply not contain the necessary token value.
Also there is a suspicious call to bundle.js, my expectation is that you should not be executing it directly. The good practices is to configure HTTP Request Defaults to download embedded resources and use parallel pool to be closer to what real browsers do.
See Web Testing with JMeter: How To Properly Handle Embedded Resources in HTML Responses article for more detailed explanation.
I have set up a load test plan with multiple thread group, i.e. -
Registration (50% of the threads)
Place Order (10% of the threads)
Some more operations (remaining threads)
Herein if Registration thread does not succeeds than I don't want to execute remaining thread groups. In case of a single thread group I can use if controller and discard samples if one sample fails but how do I achieve it when I am using multiple thread groups.
JMeter Variables scope is limited to current Thread Group only, if you want to use If Controller basing on the condition which is set in another Thread Group - you should be using JMeter Properties instead (JMeter Properties scope is global for the whole JVM). See How to Use Variables in Different Thread Groups article for details on converting JMeter Variables into JMeter Properties.
You may also find InterThread Communication plugins useful when it comes to passing data between thread groups and setting up dependencies.
However, given your scenario you either need to pass the whole thread context (cookies, cache, whatever) which might be tricky so it would be much better putting all the samplers under the same Thread Group and use Throughput Controller, Switch Controller or Weighted Switch Controller, whatever matches your scenario the closest way. See Running JMeter Samplers with Defined Percentage Probability guide for more information.
I have entered 500 to be the number of thread group and ramp up time to be 120 seconds but when the report is generated,the virtual users count is only 15 or in composite graph-active threads over time is raised to near about 12. So I am bit confuse active threads counts. Because the data(threads) or numbers that I filled in test plan before test is different and after result is different. What about scaled values in graph?and x10?Something related to threads?
Each JMeter thread representing a virtual user after initialization starts executing samplers upside down (or according to the Logic Controllers).
If thread doesn't have more samplers to execute and no more loops to iterate it's being shut down. It looks just like your case. See Max Users is Lower than Expected article for more detailed explanation and workaround.
Usually people set Loop Count to "Forever" and use Runtime Controller to so test could finish in designed time. Another option is using i.e. Ultimate Thread Group available via JMeter Plugins which provides convenient way of defining a load scenario.
I am load testing (baseline, capacity, longevity) a bunch of APIs (eg. user service, player service, etc) using JMeter. Each of these services have several endpoints (eg. create, update, delete, etc). I am trying to figure out a good way to organize my test plans in JMeter so that I can load test all of these services.
1) Is it a good idea to create a separate JMeter Test Plan (jmx) for each of the APIs rather than creating one JMeter test plan and adding thread groups like "Thread Group for User Service", "Thread Group for Player Service", etc? I was thinking about adding one test plan per API, and then adding several Thread Groups for different types of load testing (baseline, capacity, longevity, etc).
2) When JMeter calculates the Sample Time (Response Time), does it also include the time taken by the BeanShell Processors?
3) Is it a good idea to put a Listener inside of each Simple Controller? I am using JMeter Plugins for reporting. I wanted to view the reports for each endpoint.
Answers to any or all of the questions would be much appreciated :)
I am using a structure like below for creating a test plan in JMeter.
1) I like a test plan to look like a test suite. JMeter has several ways of separating components and test requirements, so it can be hard to set a rule. One test plan is likely to be more efficient than several, and can be configured to satisfy most requirements. I find there can be alot of repetition between plans, which often means maintaining the same code in different places. Better to use modules and includes on the same plan to reduce code duplication, but includes are equivalent and can be used with test fragments to reduce duplication.
Threadgroups are best used as user groups, but can be used to separate tests any way you please. Consider the scaling you need for different pages/sites. ie User/Administrator tests can be done in different Thread Groups, so you can simulate say 50 users and 2 admins testing concurrently. Or you may distinguish front-end/back-end or even pages/sites.
2) It does not include beanshell pre- and post-processing times. (But if you use a beanshell sampler, it depends on the code)
3) listeners are expensive, so fewer is better. To separate the results, you can give each sampler a different title, and the listeners/graphs can then group these as required. You can include timestamps or indexes as part of your sampler title using variables, properties and ${__javaScript}, etc. This will cause more or less grouping depending on the implementation you choose.