Need to count samples generated in thread level. I am using 8 thread groups and each thread group contains multiple transaction controller and each transaction controller contains multiple requests. Problem is here that I am able to get the samples to count for each transaction controller but not for thread level.
I am using 8 ultimate thread group in my test plan for load test executing for 1hr.
You could consider adding __threadNum() function somewhere to your Sampler's name
The function will be evaluated in the runtime and resolved into current thread (virtual user) number.
This way you will be able to see how many Samplers did this or that thread execute in a listener of your choice, i.e. in Aggregate Report
Check out Apache JMeter Functions - An Introduction article for more information on JMeter Functions concept.
Related
When I execute my jmeter script with below mentioned scenario then I get java.lang.RuntimeException in the logs and 2nd iteration/loop count APIs are not executed.
As you can see only for 1 thread APIs are visible in view result tree.
In this you can see that no APIs are executed for 2nd thread.
Runtime exception is coming.
Thread Properties
Number of threads : 1
Ramp-up period : 1
Loop Count : 2
Thread Group Used : Normal Thread Group
Controller Used : Parallel
Data is parameterized using 1 csv file only.
I also used "Transaction Controller" to verify but in that I didn't faced any issues and the threads were executing for the mentioned loop count. Is it normal in case of parallel controllers?
As per "Limitations" chapter of the Parallel Controller documentation
Parallel Controller does not support work with Transaction Controller so if used you can get an unexpected results. If you decide to use these controllers together familiarize yourself with already known problems that described in roadmap
So my expectation is that you need to remove either Transaction or Parallel controller from your test plan.
Parallel Controller is for "exotic" scenarios like handling AJAX requests when a single JMeter's thread (virtual user) kicks off one or more sub-threads
If in the reality your "Scan_API" requests are sequential - you need to remove the Transaction Controller and implement concurrency on Thread Group level
If in the reality all the "Scan_API" requests are executed at the same moment, i.e. when one user "scans" something 13 concurrent requests are fired - then you need to remove the Transaction Controller because you don't really need it, the total execution time of the "scan" would be the time of the longest request so Parallel Controller in "parent sampler" mode will return you the slowest request execution time and that would be the value you're looking for.
More information: How to Use the Parallel Controller in JMeter
Is it anyway I can have an if controller above a thread group, like:
TestPlan
-> If controller
----> Thread Group
I.e I just want to execute the if controller once so I can avoid unnecessary execution in the Thread Group?
You can add to Thread group in Number of Threads field get value from property, as:
${__P(GroupANumberOfThreads,0)}
So if you don't have property, for example don't send -JGroupANumberOfThreads=1 in CLI mode Thread group won't get executed
There are following options:
Put everything inside the Thread Group under the If Controller, this way no Samplers will be executed if the condition is not met, but the Thread Group will be still started and all threads will kick off
Set number of threads in the Thread Group to 0, it can be done using __if() function (member of JMeter Custom Functions plugin bundle, can be installed using JMeter Plugins Manager)
You can also consider running your JMeter test using Taurus tool as the wrapper, Taurus provides possibility to completely disable arbitrary test element (including thread groups) using simple declarative YAML syntax
I want to run a thread x times. The thread group contains three samplers and because I dont want them to be mixed up in the result windows I only want to start the next thread when another is finished. I don't want to use a Ramp-Up Period because a thread could take 1 to 20 seconds.
You could use 3 thread groups and module controller (to referencd in the 2 other thread groups the elements in the first one to avoid copy ) and check on test plan the option:
Run Thread Group sequentially
Your use case is not very clear, however if you need to limit JMeter to X concurrent threads only the most obvious choice would be going for the Concurrency Thread Group
As per Advanced Load Testing Scenarios with JMeter Part 4 - Stepping Thread Group and Concurrency Thread Group article:
The Concurrency Thread Group provides a better simulation of user behaviour because it lets you control the length of your test more easily, and it creates replacement threads in case a thread finishes in the middle of the process.
You can install Concurrency Thread Group as a part of Custom Threads Group bundle using JMeter Plugins Manager
Regarding your three listeners bit, I would recommend reconsidering this approach as per JMeter Best Practices you should not be using any listeners, instead of it you need to run JMeter in non-GUI mode and use -l command-line argument to specify the results file name. Once your test is finished you can open the .jtl results file with a listener of your choice or generate a reporting dashboard from it.
You can use "jp#gc - Ultimate Thread Group". The Ultimate Thread Group provides flexible thread scheduling to your test scenario. It allows us to create a scheduled thread with advanced configuration. Start Threads Count, Initial Delay, Startup Time and Hold Load Time can be defined separately for each record.
You can define tasks to run consecutively.
This platform support flexible thread scheduling. You can read detailed wiki docs about the ultimate thread group.
Link: Loadium.com/wiki/ultimate thread
I have a JMeter test plan which performs a simple action once. When I upload the test to BlazeMeter, I can then choose the number of threads I want for my thread group and run the test.
The problem I am having is that my test setup needs to know how many threads the thread group will have. To make things clearer, here is a simple representation of the test plan:
setUp Thread Group
needs to know the number of threads in the below thread group
Thread Group
The number of threads for this thread group is determined via BlazeMeter test configuration
Within the non-setup thread group, I can dynamically get the number of threads assigned via BlazeMeter, but I can't find any way of getting this number from within the setup thread group.
Any ideas?
You can do it using the following Groovy code:
def numberOfThreads = ctx.getThreadGroup().getNumThreads()
Demo:
The approach is environment-agnostic so you can use it anywhere. It may be more handy to use __groovy() function like: ${__groovy(ctx.getThreadGroup().getNumThreads(),)}
See Groovy Is the New Black article for more information on using Groovy scripting in JMeter tests.
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.