After a long period of time of reading, It's my first post here. :)
My question is the following:
Using JMeter, I have to execute 10000 requests, but between every 1000 of them, I should have sleep time (from 0 to 1000 => sleep time => from 1000 to 2000 => sleep time => ...).
I was able to do that using if clause and '__counter(FALSE,)' with pause between every 1000 requests, but it's working only on one thread. If I set >1 threads, it skipping if clause and sleep time is not activated. Far as I know, first parameter of the "counter" function makes it "global" if it is FALSE, but I am confused why the if clause is skipped, if more than 1 thread is used.
I'm checking the counter with groovy func: ${__groovy("${__counter(FALSE,)}" == "1000")}
How do you know that the "sleep time is not activated"?
Your "sleep time" will be "activated" only once when the counter reaches 1000, on 2000 and so on the condition will not be met
Inlining JMeter functions or variables into Groovy scripts is not very recommended, consider switching to __jexl3() function and changing your expression to something like:
${__jexl3(${__counter(FALSE,)} % 1000 == 0,)}
Demo:
More information: 6 Tips for JMeter If Controller Usage
Related
I have 8 threads in JMeter, which i am executing for every 5 minutes using Task scheduler.
Now i have included 2 threads which want to run for 5 times per day only (ex: at 12am, 5am,10am...)
when the moment comes, the execution shall be 8+2 & remaining time, it shall be only 8 threads.
Is it possible to configure such usecase in Jmeter..
If you're going to use the same .jmx script and want to execute either 8 or 10 "threads" (whatever it is), you can go for:
If Controller - for conditional execution of this or that test elements
__groovy() function to check current time, an example condition which trigger the test at i.e. 5 AM would be:
${__groovy(Calendar.getInstance().get(Calendar.HOUR_OF_DAY) == 5 && Calendar.getInstance().get(Calendar.MINUTE) == 0,)}
I have a slow sql query, and I'd like to limit the number of times a function can be called in one second to (3).
Lets say I have these calls, I'd like the function to do that:
call_func() -> true
call_func() -> true
call_func() -> true
call_func() -> false
sleep(1)
call_func() -> true
I placed a limit of up to 3 calls per second, and then the timer is reset. How would you do this in ruby using Process.clock_gettime(Process::CLOCK_MONOTOMIC)
https://msp-greg.github.io/eventmachine/EventMachine/PeriodicTimer.html
Your code would look something like this:
n = 0
timer = EventMachine::PeriodicTimer.new(1) do
call_func()
timer.cancel if (n+=1) > 3
end
Though in truth I think the overhead of this alone will eat into some of the 1 second that you are allocating for the SQL query, so you might end up with a situation where the query only executes 1 or 2 times within the second allocated to the timer, and I couldn't begin to predict the resource increase (memory, etc.) that adding this would create.
You may be better off simply using Threads to handle the issue. You would simply create a Thread for each query and whenever it completes, it completes. Then you could restrict the Thread pool to manage the load.
https://rossta.net/blog/a-ruby-antihero-thread-pool.html
Can you help me to explain relationship between time in Runtime Controller and Ramp_up period value of Thread group?
I tested
Number of Thread: 1
Ramp_Up Period: 1
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 5s
But with case
Number of Thread: 5
Ramp_Up Period: 5
Loop count: 1
Runtime Controller: 5s
->Elapsed time of current running test: 10s
I don't understand why it become 10s.
Could you help me to explain more?
Ramp up is the time to execute all threads, runtime is controlling each thread execution.
In your case, ramp up 5 seconds means last thread will be executed after 5 seconds. Last thread will enter runtime controller which will run 5 seconds of execution. Thus 10 seconds is the maximum of your execution.
Runtime Controller acts according to JMeter Scoping Rules so it defines how long its children are allowed to run.
Normally you should be using it in conjunction with Loop Count = Forever or -1 on either Thread Group or Loop Controller level.
So
if you want the whole test to run for 5 seconds - use "Scheduler" section of the Thread Group
if you want only certain sampler(s) to run for 5 seconds - put them under the Runtime Controller, however the whole test duration will depend on when the last sampler enters the Runtime Controller
Also be aware that JMeter "asks" threads to stop so it might take some extra time to let them gracefully shut down.
In Excel Power Query (PQ) 2016, is there such a function that can insert a "SLEEP 15 seconds" before proceeding? Not a pause, but a sleep function.
Problem:
I wrote a function in PQ to query: https://westus.api.cognitive.microsoft.com/text/analytics/v2.0. That function works fine, as designed.
I have a worksheet with 10K tweets that I want to pass to that function. When I do, it gets to ~60 or so complete and I get an ERROR line in PQ. A look at Fiddler says this:
message=Rate limit is exceeded. Try again in 11 seconds. statusCode=429
I think if I insert a SLEEP 5 second (equivalent) command into the PQ function, it won't do this.
Help & thanks.
You want Function.InvokeAfter
Function.InvokeAfter(function as function, delay as duration) as any
Here's an example:
= Function.InvokeAfter( () => 2 + 2, #duration(0,0,0,5))
Returns 4 after waiting 5 seconds.
To answer a question you didn't ask yet, if you're going to execute the exact same Web.Contents call a second time, you may need to use the
[IsRetry = true]
option of Web.Contents to indicate you actually want to run the web request again..
I am performing load test with these parameters :
threads=4
ramp_up_period=90
loop_count=60
So according to above numbers, my assumption is that each one of the four thread will be created in 22.25 seconds and this 4 thread cycle will be repeated 60 times.
Below is the load test summarized report :
According to JMeter manual ramp up period is :
The ramp-up period tells JMeter how long to take to "ramp-up" to the full number of threads chosen. If 10 threads are used, and the ramp-up
period is 100 seconds, then JMeter will take 100 seconds to get all 10
threads up and running. Each thread will start 10 (100/10) seconds
after the previous thread was begun. If there are 30 threads and a
ramp-up period of 120 seconds, then each successive thread will be
delayed by 4 seconds.
So according to above scenarios approximate total time for executing load test with mentioned thread group parameters is :
TotalTime = ramp_up_period*loop_count
which in my case evaluates to 90*60 = 5400 seconds, but according to summariser Total Time is coming 74 seconds
JMeter version is 2.11.
Is there is any problem in my understanding or there is some issue with JMeter ?
Initially JMeter will start 1 thread which will be doing something, which is under your Loop Controller. In 30 seconds second thread will join, in 30 more seconds 3rd thread will start and finally on 90th second 4th thread will start.
Starting from 90 second 4 threads will be doing "what is under your loop controller".
There is no way to determine how long it would take, especially under the load. If you need a load test to last approximately N seconds you can use Duration input under Sheduler in Thread Group.
If you want to forcefully stop the test if certain conditions are met there are 2 more options:
Use Test Action Sampler
Use Beanshell Sampler
Example Beanshell code (assumed to be run in separate thread group in endless loop with reasonable delay between firing events)
if (currenttime - teststart > Long.parseLong(props.get("test_run_time").toString())) {
try {
DatagramSocket socket = new DatagramSocket();
byte[] buf = "StopTestNow".getBytes("ASCII");
InetAddress address = InetAddress.getByName("localhost");
DatagramPacket packet = new DatagramPacket(buf, buf.length, address, 4445);
socket.send(packet);
socket.close();
} catch (Throwable ex) {
}
}
TotalTime would be that if you were working without concurrency. When working in a multi-threaded environment it can happen that thread 1 is already performing its second call when thread 3 is still firing up.