According to docs I can use JMeter Thread scheduler with Duration and/or Startup Delay which override End time and Start time respectively.
You can configure Duration (seconds) and Startup Delay (seconds) to
control the duration of each thread group and the after how much
seconds it starts. When the test is started, JMeter will wait Startup
Delay (seconds) before starting the Threads of the Thread Group and
run for the configured Duration (seconds) time. Note those 2 options
override the Start time and End time.
Alternatively (although not recommended as not very flexible) you can
use the two other fields Start time and End time.
But in JMeter UI I can't delete Start time and End time, because if I delete its values it return with current time although irrelevant.
Before
After:
Is it a bug or there's a reason for that behavior?
When you define Duration and Startup delay, they override Start Time and End Time.
The latter options should be avoided and in upcoming JMeter 3.4, the 2 fields have been removed.
See:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61549
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)
what is the meaning of the duration in jmeter thread group.
I found this is official document saying that is end time while the startup delay is the start time.
But is it the end time since we start executing the test? or since the thread is created?
When I set the 50 threads and duration 1s, the first timestamp in the output file is 1607391972250 (2020-12-08 09:46:12.25), the thread-50 only send HTTP Request 1 in timestamp 1607391973232 (2020-12-08 09:46:13.232). So it cannot be the end time since each thread is created
But when I set 1000 threads, the timestamp of the last several thread will exceed 1s than the timestamp of first thread's first request. it cannot be the end time since the we start executing the test
So what is the real meaning of the duration?
Duration is neither the start time nor the end time but the timespan between the two.
If your total duration is 1 second and your ramp up time is 1 second it might lead to a bit confusion since some of the threads have only just started when the whole test is already over. The duration starts counting when you either hit the "play button" in the GUI or start the test via command line.
Startup delay will mostly make sense if you have several thread groups inside your test plan and want some part of the virtual users to start at a later point for either logical reasons (e.g. thread group A generates forum posts and group B starts searching those forum posts after 1 minute) or for some kind of load shaping (might be achievable within one thread group though). This is relative to the test start.
Anyway JMeter is a tool mostly used for load and performance testing. In this type of testing you will usually have the tests run for minutes or hours. So from my perspective your question is mostly theoretical unless you want to achieve something very specific which you did not further elaborate.
As per Thread Group documentation:
Specify Thread lifetime If selected, confines Thread operation time to the given bounds
Duration (seconds) If the scheduler checkbox is selected, one can choose a relative end time. JMeter will use this to calculate the End Time.
So "Duration" limits the maximum duration of a given single thread, JMeter starts threads within the bounds of the Ramp-Up period.
In your case you have Ramp-Up time set to 1 second and Duration set to 1 second, it means that JMeter will start 50 threads in 1 second (so the last one will be started in 1 second after test start) and then the last thread will be terminated in another 1 second so its total lifetime plus the time required to execute the first sampler if its response time is more than 1 second
You may find Custom Thread Groups easier to use, all of them provide easy configurable visual way of defining the workload, you can install them using JMeter Plugins Manager
I'd like to, independently of any other config regarding amount of threads, ramp up time or anything else, just stop the test if it has been running for more than, for example, 2 hours.
Currently you have in Thread Group Scheduler Checkbox, when you click it
You can define Duration in seconds,
In your case for 2 hours enter 7200 (60 *60 *2)
Another option is putting all requests in Runtime Controller with similar value.
You can also do scripting in While Controller with check time (similar to Dimtri T answer):
${__groovy(${__time(,)} - ${TESTSTART.MS} < 7200000,)}
I have to test ramping up 1 user every minute for 10 minutes and then then ramping up 20 users ever minutes for next 10 minutes with jmeter. I tried to search on internet, seems like I need to use ultimate thread? If so can someone please give me an example of above scenario?
You can use multiple regular thread groups and in Test Plan,you can select Run thread Group consecutively.
Ultimate Thread plugin allows fine grained control of user threads. It will certainly achieve the concurrency pattern you're looking for. You can also start a thread group delayed with just out-of-the-box Jmeter though:
Use 2 thread groups, and set the required ramp up rates for each thread group. Since you need the second thread group to kick in 10 minutes after the test starts, add a startup delay of 600 seconds.
The relevant jmeter documentation is in Section 4.1 here:
Version 1.9 introduces a test run scheduler. Click the checkbox at the bottom of the Thread Group panel to reveal extra fields in which you can enter the start and end times of the run. When the test is started, JMeter will wait if necessary until the start-time has been reached. At the end of each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise the test is allowed to continue until the iteration limit is reached.
Alternatively, one can use the relative delay and duration fields. Note that delay overrides start-time, and duration over-rides end-time.
It is possible to do with 1 ultimate thread group.
Your setup should be as given below. You did not mention the test duration. I assumed it as 3600 seconds.
1st Row : We will have 10 threads in 600 seconds by starting a thread every min.
2nd Row: We will have additional 200 threads (ignoring the first 10 threads), in the next 600 seconds by starting 20 threads every 1 min.
We need a wait for 600 seconds in the second row which is update in Initial Delay field for the first row to complete.
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.