I'm trying to run a scenario that ramps up each thread by logging them in once, loops through an business action for an hour with pacing, and logouts as it ramps down.
Ideally the threads should not log out all at once, as such it I wanted to find a way to execute a logout action for each thread ramping down.
I have tried using stepping and ultimate thread groups, however for ramp down, the threads are being stopped.
In addition, I have tried the following scenario: 1) login, 2)runtime controller scheduled for one hour with the business action, 3) logout. This however, results in premature aborts for the threads that are still executing the business action once it reaches one hour.
Any help, even implementing this in beanshell, would be greatly appreciated.
You can just use a TearDown Threadgroup. That will always be executed once your test is over.
You can use a thread group which sets a jmeter property, let's call the property "isRunning", in a pre or post processor, next that thread has a test action set to pause for the duration of the test. After the pause set the property "isRunning" to false.
When the user logs on in another thread group (your test case) grab the "isRunning" property and store the value in a jmeter variable for the thread. Once the user logs in put your business case in a while loop with the jmeter variable created using the "isRunning" property as the condtion.
Get the value of the "isRunning" property somewhere towards the end of your business case and update your jmeter variable. Put the log out controller outside of the while loop. When the first thread group sets the "isRunning" to false, the while loop in your other threads will finish executing the use case and log out when it sees that the while condition is no longer met.
If you use any type of random think timers and ramp time, the threads should essentially step down on their own, due to ramp time offsetting the start of the use case and random think times.
Not sure if this is the best way to go about this, but I needed to do the same thing you are looking for and this proved to be a feasible workaround.
Related
I need to run a jmeter test with N users over the course of a fixed time period. I am planning on using an "Ultimate Thread Group" for this as it meets my requirements. However, at the end of the time period and during the ramp down it simply kills threads even if they are not finished. This causes me problems because I end up in a situation where I have half completed records left lying around. Is there any way, either using this type of thread group or any other type to do as I require?
I have already got my test script ready, and have been exploring different thread groups and UTG seems like the best option, apart from the fact it kills threads without waiting for completion.
I would recommend to use stepping thread instead of ultimate thread group, this will surely help you out with your scenario. You can adjust stepping thread parameters according to your needs.
I'm trying to make a part of my thread group to be executed only in a last iteration of a thread. A thread will be stopped at some moment of time (by pressing stop at gui while debugging, or by sending stoptest.sh signal to the headless load stations during the load test itself), so I don't know, how many iterations will be executed to that moment. If I knew the exact number, I'd use an If controller with condition like ${__iterationNum} == 50, but that's not the case.
There is a tearDown thread group for such a thing as far as I know, but I need to access my threads local context for the operation I am executing. So basically the question can be asked as - What's the way to determine a "Stop_thread signal was allready sent, and the current iteration is the last one executed"? If i knew how to get it, I could then implement an If controller.
Hope I explained it clear enough, thanks in advance, guys
PS Jmeter 4.0
Building a test plan in JMeter. I have different Transactions and each of them has number of HTTP samplers and "if conditions".
So basically each user might not perform the same action based on the "if condition". I want all the users to start performing the same transaction at the same time and also wait for the other users(Threads) if they have not reached to the current transaction.
I know that I can achieve this with the help of Synchronizing timer but somehow I am not able to achieve this with it.
How to achieve it with any possible method ?
PS - I just want the threads to start transaction at the same time. it does not matter if they performing same sampler or not.
I can suggest another approach,
You can use tearDown Thread Group,
execute after the test has finished executing its regular Thread Groups.
After all threads are done you execute tearDown and can execute anything you want, including Module Control which can reuse transaction from your main thread group
It is quite hard to guess what's going wrong without seeing your Test Plan structure. Just in case be aware that Timers obey Scoping Rules so if you want a request to be executed by N threads in parallel - you need to put the Synchronizing Timer as a child of this request.
See Using the JMeter Synchronizing Timer article for comprehensive information and example test plan.
I have what I assume is a common scenario, and while I believe I have a working solution, it feels like there's probably a better way.
The issue is that I need finer granularity than the Thread Group-level Action to be taken after a Sampler error behavior. Some of my samplers represent requests that would prevent further execution of a workflow on failure. In these cases, rather than barreling ahead with subsequent requests that a real user could not make and that would fail anyway, I want the thread to move on to the next iteration loop, starting from scratch, as it were. Other samplers represent requests that would continue to be made even if some of them failed. In these cases, I want the thread to keep going.
The method I'm using now, which is clunky but seems to work, is as follows: at the Thread-Group level I have set the Action to be taken after a Sampler error to be Continue. I assume this means that by default, if a Sampler fails, the thread will continue with the next instructions until it reaches the end.
This leaves requests that I want to block/halt/restart the workflow on a failure. The solution I have found is to follow each of these Critical Actions with an If Controller:
The condition !${JMeterThread.last_sample_ok} should resolve to true if the previous Sample failed. Within the If Controller, I have a Test Action to stop execution and start the next loop iteration of the thread:
I assume Go to next loop iteration means to start the thread over, assuming the Thread Group is set up with a loop count.
This set up seems to work, in that the thread starts over at the top of the tree each time a Sampler fails and is followed by this If/Action combo. Samplers that are not followed by this block do not halt execution on a failure.
This set up also seems very clunky, and annoying, since I'm copy-pasting this failure conditional all over the place. Is there a more elegant way of getting this behavior, or have I hit upon the more-or-less right way of doing this? Thanks!
Your solution is fine except for copy/paste as you say, so the solution is to use:
Test Fragment will contain your IfController:
Module Controller will point to it:
I've got a pretty basic test plan in JMeter consisting of a Thread Group and a bunch of HTTP Requests separated by Timers and a Summary Report. I notice when I watch the report that all 10 of my threads make the first request, then pause for some time, then all make the second request.
Is it possible to have each thread execute the full script independently of the others so that (given a Ramp-up delay) you have overlapping workload, i.e. some threads executing the first step while others are on the 3rd or 4th etc?
Threads DO execute independently in JMeter.
Make sure you are you using any Ramp-up period in the thread group definition.
Another reason for what you're seeing is probably due to using a constant timer which ends up in requests looking they they are synchronized. If you simply change it to one of the Random timers you'll get more randomness in the delay between requests.
Here are two good sources about timers:
http://performancetestersdiary.wordpress.com/2013/03/06/jmeter-timers-in-pictures/
http://www.softwaretestingclass.com/timers-in-jmeter-tutorial-series-6/
Yes, Threads DO execute independently in JMeter, but,if you start at the same time and do the same things, all the requests will be issued at the same time (specially if you are using a constant throughput timer).
I use two way of approaching this problem:
use a uniform random timer under a "once Only controller", at the beginning of the thread.
The value of the timer should be close equal or close to the time it takes to execute the service.
use rampup time (same value as above). It is deterministic and simpler to use (which can be bad or good, according to your needs.
Click on your "Test Plan"
Check/Select the Property: Run Threads consecutively (i.e. Run Groups one at a time)
Hope this will help.