Im currently trying to Ramp-Up threads on a random timer but could not find a satisfying solution so far. I want to start a new thread every 4 to 12 (Random) Seconds.
Is it somehow possible to Ramp up threads based on a groovy script?
I tried using "${__Random(4,12)}" inside the Threads scheduling Parameters of the Stepping Thread Group but this is only executed once resulting in starting all the threads with the same time increment
I don't think you should be going into that direction because tests need to be repeatable hence using random delays in ramp-up is not something you should be normally doing.
If despite the above warning you still want to implement it I would recommend considering using a Constant Timer, if you put it as a child of the first request it will introduce a delay before this request and you will be able to use __Random() function there but make sure to convert seconds to milliseconds like ${__Random(4000,12000,)}
If you need to delay the thread start event for the random amount of time I'm afraid that this is not possible using either existing Thread Group or Custom Thread Groups so you will either need to implement your own thread group by creating a new JMeter Plugin or alternatively you can kick off new JMeter threads from JSR223 Sampler like
ctx.getThreadGroup().addNewThread(org.apache.commons.lang3.RandomUtils.nextInt(4000, 12000), ctx.getEngine())
Related
I am trying to configure a test for signup-login with invalid credentials imitating bruttforce attack. However, I want to make requests as a single user.
So the scenario is the next:
Request to sign up with valid params;
Attempt to log in with invalid params in a loop.
I am adding throughput timer but then I need to set up a high number of threads to generate for example 1 request per second.
How can I set exactly one user and run only one request per second in a loop?
UPDATE - SOLUTION
Everything was rather simple but still strange for me.
Maybe someone will face the same problem.
To get a number of requests per one user throughput timer should be placed not inside the controller but inside the thread itself.
To achieve Target Request Per Second use Throughout Shaping Timer : How to use Throughput Shaping Timer
JMeter Plugin link : Download from here
Few Important Notes:
JMeter threads of Thread Groups in scope of the Element will be
stopped when RPS schedule finishes.
Provide enough working threads for your RPS, JMeter timers can only delay threads (and limit RPS). You may pair this plugin with Concurrency Thread Group using Schedule Feedback Function to dynamically maintain thread count required to achieve target RPS.
If you're using versions of JMeter lower than 3.3 and if you have RPS that lower at the end of test, make threads to lower also. Оtherwise you'll have a spike in last second.
Avoid using zero RPS value as start of test, this produce spike also
Avoid zero RPS during the test, this may lead to nasty effects
Now, practical example showing 1 RPS for 1 User:
You might want to reconsider the location of the timer, it obeys JMeter Scoping Rules so it gets applied to all Samplers which are in your Thread Group.
If you want to apply it to only one - make it a child of the relevant sampler.
Also be aware that Constant Throughput Timer is precise enough on minute level so you might want to switch to the Precise Throughput Timer
I would like to execute a loop of HTTP requests with an incrementally number of users.
For example, I want something like that :
1st loop : 1 user
2nd loop : 2 users
3rd loop : 3 users
...
Is that possible with the JMeter GUI ?
Thanks in advance !
You can achieve this effect by using the Stepping thread group plugin
You can gradually increase the number of concurrent users in JMeter. But not in the way you are actually asking ie, every loop / iteration!
Simply - You can not change the thread count within the test once the JMeter test has started running . But you can use variables for the user count and supply to the test before the test starts.
To gradually increase the user count, you can use any of the below thread groups
You can use the regular thread group, ramp-up period. 100 users and 1000 seconds ramp up period, will add 1 user every 10 seconds.
Stepping Thread Group
Ultimate Thread Group
Actually JMeter doesn't allow this, however you can work it around using different approach, for instance if you stick to Requests Per Minute rather than to Virtual Users.
You can use Constant Throughput Timer to set desired initial throughput (i.e. N requests per minute) and increment it by desired factor each Thread Group iteration.
Despite word "Constant" in its name the throughput doesn't have to be constant, it can be a JMeter Variable or Function or JMeter Property.
Reference material:
How to use JMeter's Throughput Constant Timer
Beanshell Server
Throughput Shaping Timer - an advanced version available via JMeter Plugins, has some extra scheduling capabilities.
I am have been exploring JMeter for the last couple of days. And I am try to achieve the following:
I am trying to create a load test for a service such that, in the first loop 'n' threads are created and in the second loop 'n+m' threads are created and in the third loop 'n+2m' threads, in the fourth 'n+3m' threads and so on. I did find many solutions here and I tried replicating them, but somehow it is not working for me. The test plan I created looks something like this:
Step 1: Add a user defined variable called USERCOUNT = 0
Step 2: Create a thread group. I have used __intSum to increment USERCOUNT by one and storing the result back in USERCOUNT for future reference.
Ideally what I am expecting here is, in the first loop one thread is created, in second loop 2 thread are created and in the third loop 3 threads are created. So in total there should be 6 thread created. However the results show up something like this:
Not sure if I am missing something silly or my approach itself is completely wrong. Any help from the community would be appreciated. :)
I believe what you are trying to do is impossible. When JMeter starts a thread group for the first time it initializes the number of threads.
What you are essentially trying to do is re-run the same test three times with different numbers of users each time. JMeter cannot re-run a thread group once started, it can only re-run ("loop") a thread in a thread group. It is not possible to add threads to a running thread group once the ramp up and threads are initialized. (Let me know if I should try to explain that further).
If you want one thread group to populate the run-time settings of another thread group, you must have two thread groups in the test plan. At the test plan level, check off the option "Run Thread Groups Sequentially."
With that option, JMeter will not initialize the number of threads on the second thread group until the first one finishes. The first thread group can set a global property, and the second thread group can reference it in the number of threads.
How to set a property in beanshell: (this would be in Thread Group 1)
props.put("threadgroup_2_num_users","15");
How to reference that value in Thread Group 2:
${__P(threadgroup_2_num_users)}
If this does not help, maybe try to describe your end goal. What are you trying to learn about the thing you are testing?
Edit: Perhaps using the plugin package "Stepping Thread Group" will allow you to achieve the scenario you are trying in a single thread group. Check this out:
http://jmeter-plugins.org/wiki/SteppingThreadGroup/
JMeter currently doesn't provide possibility to change number of threads on-the-fly during test execution so I would suggest to go with the following alternatives:
Use i.e. Ultimate Thread Group available via JMeter Plugins which adds some extra features to JMeter's Thread Group so you will be able to implement your scenario
Consider so called "goal oriented scenario" when load is based on requests per second rather than on number of virtual users. You can precisely set desired throughput rate and even change it during test run using Constant Throughput Timer
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'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.