I don't know if I have placed the timer at the correct location. I am not able to get Precise Throughput Timer working.
Any JMeter component needs to be placed according to JMeter Scoping Rules
How do you expect the timer to "work" given you have only one thread and one iteration in the Thread Group especially given your test finishes in 500 milliseconds and you configured the test duration as 500 seconds
If you want to limit your test throughput to 1 request per second for 1 thread and 1 iteration only - I can only think of introducing pacing as none of the existing timers won't be able to do this given that short test duration
Related
In Jmeter, I am using Concurrency Thread Group with ${__tstFeedback(ThroughputShapingTimer,1,10,10)} in combination with the Throughput Shaping Timer to dynamically change the target throughput throughout the test duration.
I want to have a JSR223 test element (Assertion or PostProcessor, does it matter?) in which to write custom logic to not log some specific error but only if it occurs near the end of the test script and I don't want to hardcode the time value.
For example if I get a java.net.SocketException in the last 2 minutes of the scheduled run time, I want to not log it, but I do want to log it in the rest of the time.
For this, I suppose that I need some way to grab the date when the test is supposed to end since the beginning of the test, evaluate it and subtract 2 minutes from it and then compare the current time with that time and then if the current time is higher, then start doing some logic to exclude the result from the logging.
Update: In the "Normal" or "Default" Thread Group I noticed that I can do this to get the initial duration:
String groupDuration = ctx.getThreadGroup().getDuration();
log.info(groupDuration)
But for the Concurrency Thread Group it does not work the same.
I would appreciate any information to help me achieve this goal.
If your Concurrency Thread Group is configured with a Throughput Shaping Timer and Schedule Feedback Function the scheduled test duration is available through a property exposed by the Throughput Shaping Timer.
props.get('elementName_totalDuration')
The element will export the following propertyy that you can access through __P function or using in JSR223 Test Elements props.get("property name")
elementName_totalDuration - Total duration as sum of the
"Duration,sec" column
elementName will be the name of your Throughput Shaping Timer
NOTE
You should set Hold Target Rate Time to a value equal or greater than the total Duration specified in the Throughput Shaping Timer schedule. Hence set this value to a very high value to avoid test completing before scheduled duration in Throughput Shaping Timer. e.g Set Target Hold rate t0 1440 minutes.
Using concurrency Thread Group with Throughput Shaping Timer and the Feedback Function
When this thread group is used with Throughput Shaping Timer, you may replace Target Concurrency value with a call to the tstFeedback function to dynamically maintain thread count required to achieve target RPS. When using this approach, leave Concurrency Thread Group Ramp Up Time and Ramp-Up Steps Count fields blank, but be sure to set Hold Target Rate Time to a value equal or greater than the total Duration specified in the Throughput Shaping Timer schedule.
For dynamic thread groups and derivatives you can use the following function:
ctx.getThreadGroup().getHold()
If you need to determine whether it is in minutes or seconds you can use
ctx.getThreadGroup().getUnitStr()
Example:
More information on Groovy scripting in JMeter: Apache Groovy - Why and How You Should Use It
You can filter results after test with Filter Results Tool
If you want to remove the ramp-up phase, you could use offset filters
Using --end-offset 120 parameter (seconds)
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 am quite new to jmeter and try to do a performance test of my application. I want to generate 100 request per second scenario however my server takes 3-4 secs to respond to every request. I am running my test for 1 mins which means number of requests fired should be 60k within the time span. However jmeter actually waits for the response before it sends next request. Which is not what I am looking for.
How can I make sure that jmeter sends a new requests every second with 100 req/sec without waiting for the response so that the number of requests fired per min is 60k.
I am trying to use constant throughput timer with 60k as request per min, however that is not helping. Here is my test screenshot.
EDIT
I have done like this
And Throughput shaping timer being as
So ideally I should get number of samples as 3000?, still not getting that.
Make sure you provide enough threads (virtual users) under Thread Group, "vanilla" JMeter won't kick off any extra threads if actual throughput is less than target one you specify in the Constant Throughput Timer.
Another solution would be using Concurrency Thread Group along with the Throughput Shaping Timer. They can be tied together via feedback loop so if you use these test elements JMeter will start more threads if the current amount won't be enough to reach the desired requests per second rate.
You can install both using JMeter Plugins Manager
My suggestion is to consider using the Arrivals Thread Group. This TG will allow you to configure the desire average throughput (ATP); the TG will instantiate the required threads needed to achieve the ATP goal.
I am working on stress test, but my first sampler floods server with tons of requests with very little amount of time, so I want to make a delay between each thread using request.
Test structure:
Thread1 - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread2 - Sampler1 (for example: access login form)
Delay (custom seconds)
ThreadN - Sampler1 (for example: access login form)
Delay (custom seconds)
Thread1 - Sampler2
Delay (custom seconds)
Thread2 - Sampler2
Delay (custom seconds)
<...>
Synchronizing Timer
All threads realeased with final sampler (this part works)
I tried to put timers as samplers parents or childs. Probably I am missing something, because non of the timers are working for me.
I've found similar problem solutions, but non of the worked for me:
JMeter - sharing a delay between requests across multiple ThreadGroups
Delays for each thread in Ultimate Thread Group
I would suggest using the stepping thread group via http://jmeter-plugins.org/wiki/SteppingThreadGroup/.
In the 'thread scheduling parameters' section, you'll note you're able to specify the maximum number of threads to run at peak, but you're also also to slowly instantiate threads as you need them.
Very plainly, the setup below says "When I run this test, I'm eventually going to want 100 threads, but when I first start the test, wait 15 seconds, then only start 10 threads. Then add another 10 threads every 120 seconds. Once we reach max threads, keep working for 180 seconds, then slowly peel off 5 threads every 15 seconds.
This should meet your need.
As per your Test Plan description, you can use 1 of the timers mentioned below:
Gaussian Random Timer
Constant Timer
Hope this will help..
Constant Timer would be best option as per your mentioned requirement.
You can use 'Ultimate Thread Group' instead of regular Thread Group. There is 'Initial Delay' in ultimate thread group which will help you to achieve your requirement.
I am running my load test for a duration of 1 hour,in between the test I want a scenario to run for a duration of 1 minutes at regular interval of 15 minutes.
In jmeter,currently I am able to simulate for all the others scenarios except for the burst mode.
How do I keep the delay for 15 minutes and trigger the request for duration of 1 min?
How do I achieve the TPS for the burst? Currently I have to manually trigger jmeter script.
I would suggest doing the following:
Add a separate Thread Group.
Configure ramp-up and thread count as required.
Add a Constant Timer, set Thread Delay to 900 000 (15 minutes = 900 seconds, 1 second = 1000 ms)
Add a Runtime Controller, set Runtime to 60.
Add a Loop Controller, set Loop Count to Forever.
Place your burst test logic under the Loop Controller.
If you need to define requests per second rate during spikes use Constant Throughput Timer
I came here since I had the same issue or similar issue of "simulating" burst like request during the load test. I tried to follow the accepted answer but didn't get it to work (perhaps I misunderstood some steps), anyway; I based my solution in #esteveavi comment Loadtesting in burst mode in Jmeter from the original post above. And ended up using JMeter's "Ultimate Threat-Group" plugin with something like the following test plan set up: