I have a script with one Thread Group, and I have a look count on so when I run the test it will do 4 iterations of that one thread group.
I am trying to add a delay between each iteration of the thread group NOT between each request in the thread group so that after the first iteration it will wait 5 minutes then do the next iteration.
I have looked all over for a solution but all answers refer to each request as opposed to the entire thread group.
You can add Flow Control Action at the start of thread group with Pause Action
Duration
How long to pause for (milliseconds)
This sampler can also be useful in conjunction with the Transaction Controller, as it allows pauses to be included without needing to generate a sample. For variable delays, set the pause time to zero, and add a Timer as a child.
JMeter Timers:
Obey JMeter Scoping Rules
Are being executed before samplers
So if you want a fixed delay between iterations just add a Constant Timer as a child of the first Sampler in the Thread Group and the delay will be applied.
Related
In my TestPlan in jmeter I have around 50 thread group and I want to run those multiple times but 2nd iteration should only start when all the 50 threads are executed once.
There is a loop count field in jmeter but it do not solve my problem instead it runs each thread X number of times before start executing next thread.
Can anyone help me out?
Thanks in advance
Put all the transaction/Request under one thread group and no. of threads as 1 and control iteration with loop count. Since, you want to execute only once and in sequence. Though, it is not the exact answer but another way to doing it.
I have a single thread C program implemented using event driven programming - a callback triggers every time the event happens.
The callback takes way too long to execute (do a bunch of calculations) and this processing time is important. Currently is 500 microseconds and need it to be less than 100.
Most of the calculations are independent, can be done in parallel.
I have a machine with many cores and was thinking if getting multiple threads to make the calculations in parallel could be possible / of help.
I think that the approach in which at the beginning of the callback I generate multiple threads, and then send the different calculations to the multiple threads will not work well because generating the threads takes time.
Is it possible to have a few threads up, waiting to be used, and that every time the callback is triggered I can send the calculations there without having to generate the threads in each callback?
You can use a thread pool for this (often called a worker pool). The basic idea is create some number of threads in advance and have them all sleep, waiting on a semaphore whenever there is no work to do.
Your code will be simpler if you can get away with one thread for each processing task, but you can also implement it (carefully) with a queue, where each worker tries to handle the next job in the queue and then sleep when the job queue is empty.
Either way, a single round of processing will look something like this:
assign or queue tasks to your worker pool
notify worker pool to wake up and begin processing tasks
wait for worker pool to signal all tasks complete (*)
(*) remember, "all tasks complete" is not the same as "task queue empty"
Now your main timing bottlenecks will depend on the mutex/semaphore implementation and your OS thread scheduler. It may be appropriate to set a high priority on all your worker threads.
If you have events at regular intervals, a common improvement to the above is to also double-buffer (i.e. output the result for the previous event, and assign the workers to begin processing input for the current event). To achieve that, you would move step 3 to happen before step 1.
This may or may not be suitable for your purposes. But it can provide some extra leeway with timing, if you're still having trouble processing fast enough. Try something simple first. Problems like this can get hairy very quickly when you start introducing extra requirements.
The usecase
I'm writing a C program which needs multiple timers. I had first written a fast prototype which started a pthread for every timer. Just a simple while-loop with a sleep command because 1 second resolution is enough.
But with more than 10 timers it's not a very efficient nor production grade code quality. Therefore I wanted to use an eventloop. I've read several times about libuv and thought to give it a try.
So my idea was simple. Have 1 timer thread which runs the timer eventloop and add and remove timers on the fly. The timers are very simple countdown timers which execute a function pointer when they reach 0 and which can be canceled. So no repetition is needed.
The problem
I think the real problem here is documentation, the libuv docs simply aren't very clear on how to achieve this. So I think the code I currently have is rubbish. Let me walk you through it.
At the beginning of my program I'm starting a phtread with the following entrypoint:
static void* _uv_loop_thread_entry_point(void *args)
{
/* Initialize the timer event loop */
timer_event_loop = malloc(sizeof(uv_loop_t));
uv_loop_init(timer_event_loop);
/* Keep running the eventloop */
while(uv_run(timer_event_loop, UV_RUN_DEFAULT) == 0) {
/* Wait 1 second for new handles */
sleep(1);
};
/* The timer event loop has stopped, free all resources */
uv_loop_close(timer_event_loop);
free(timer_event_loop);
return NULL;
}
Than whenever I want to use a timer I would do the following:
uv_timer_init(timer_event_loop, uv_timer);
uv_timer_start(uv_timer, timeout_ms, ??);
Now I have several questions:
How to use the timer without repetition
Where do I set the callback function for this timer
How can I know how much time is left in this timer
I can really use some help on this subject.
Update 1
Ok, I'm making some progress and it basically works. The libuv event loop runs in a separate thread. And to already answer some of my questions:
When the last argument in uv_timer_start is 0 the timer will not repeat itself.
The callback for the timer timeout event is the second argument of uv_timer_start
I don't yet know the best answer to my third question. But for now I keep track of the time when my timer has started and the current time and take the difference. I than substract the difference from the total time of the timer to know how long it will take before the timer will end.
I would still like to know if my uv_run implementation is correct.
Kind regards,
Daan
You are playing in undefined behavior territory. libuv is not thread-safe see the docs here So while running the loop in a thread is ok, creating a timer in another thread while the loop is running is not.
You can still do it by using a uv_async_t handle and a semaphore: uv_async_send is thread-safe, so you would call it from the outside, stop the loop and signal a semaphore. The calling thread would wait until the semaphore is signaled. At this point the loop is stopped, so it's ok to create a new timer and add it.
There is no API to know how much time a timer has left.
If all you need is a loop to control some timers libuv might be overkill. You could use timerfd if you're on Linux, or a hand-built event loop which only does timers on top of select for example.
Hello everyone i have a question about timeouts in c so i ask you guys.
So i'm making a server application in C that uses POSIX threads to accept multiple simpultenious connections but implementing timeouts was harder than i expected as i read the message (HTTP requests) in parts first the start line than the headers etc, etc, and i initialy used select() to detect if the socket was ready for reading but that way if the client sends the start line only than the server will continue waiting for the headers and body without ever timing out so what i did is i put all the code that reads the message in one function and i wan't to implement a timeout for the entire function, say if the function doesnt return in x seconds than a timeout function is called and the thread is exited...
[Things that i have tried]
putting multiple select calls (one for every socket read) but that ended up in a mess of having to calculate remaining time for each operation.
i didn't actually try to use an alarm signal as i've heard that signals effect the entire process and not a specific thread that would cause one time out to timeout every parallel connection..
thanx in advance.. B)
There is no proper way to terminate a thread function other than letting it finish.
Every attempt to finish a thread from the outside could lead to resource (mostly but not only memory) leaks, state variables in nondeterministic state, and so. Please don't do it. Never. The normal way of terminating a thread function from the outside is to make it listen to some means of inter thread communication (which can be a sync object, a volatile variable or even a message loop), and exit the function core when it is necessary. Normally you would realize it by having a single test in the cycle condition of the thread if it is looping or testing before every long-running operation inside your thread.
Now if you store the timestamp of the function start and test at every cycle condition/long-running test if currenttimestamp > timestamp + timeout, you can exit from inside your thread and voilá; your problem is solved.
Suppose inside a thread group with delay thread creation until needed option selected,if we add a constant timer of 30 seconds before a http request,then the thread should get created after 30 seconds right?
That is the number of active threads should be zero for 30 seconds.But i am not getting that.When I start running the threadgroup,the number of active threads started increasing.
Timer comes into place while sending the samplers. Not for thread creation. If you want to delay thread creation by 30 seconds, you should have enough ramp-up period.
If you have 10 users, give the ramp-up period as 300 seconds. You would see a thread being created for every 30 seconds. (assuming delay thread creation until needed option selected)
To add a little more detail to Vinoth's answer:
JMeter allocates all threads at the test start unless the Thread Group option "Delay Thread creation until needed" is selected.
In some cases where a test has a very large number of threads the CPU can spike to 100% and kill the server process if the delay thread creation option is not selected.
When selected, JMeter will allocate threads according to the ramp up times. Otherwise all threads are allocated to the JVM process the moment the test is started, regardless of ramp up time.
This has no relation to whether or not the threads are allowed to begin sending samples. That always depends on ramp-up time and and test plan timers.
-Addled