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
Related
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.
I am having a small issue which I'm not understanding quite entirely.
So basically I have a thread which is waiting on an event and a timeSetEvent from WinMM which is pulsing the event every 1ms.
I put some query performance counter in my thread to find out the the time distance between each thread start. The thread is currently just waiting for the event and checking its own rate and doing nothing else.
I verified that he WinMM is correctly scheduled every 1ms, however, once the event is signaled, sometimes my thread is being preempted and runs ~6ms later than expected. At this point I started playing with priorities and affinity. So i cranked up my priority class to real time and my threads to time critical. And when on core 0 my thread still gets preempted every now and then (~1-2 times every 15 seconds). Instead if I set the affinity to core 2 it never gets preempted (like never ever, I ran the test software for a few hours, never got prempted once). Are there some driver/system threads running with priority above real time/time critical that are bound to core 0 only?
I am running on windows 7 pro on Intel i7-3470.
Sleep() is very accurate, so for example if I want to sleep for 10 hours:
Sleep(36000000); // sleep for 10 hours
My thread will wait for exactly 10 hours (plus the time that Windows needs to wake up my thread, which is negligible).
However, since Sleep() will block my UI thread, I which to use Windows Timers instead. So is a Windows Timer as accurate as Sleep()? that is, will it wait for exactly 10 hours (plus the time it needs for my Window Procedure to receive the WM_TIMER message)?
Yes, the basic plumbing underneath Sleep() and SetTimer() is the same. Something you can see by calling timeBeginPeriod(), it affects the accuracy of both. It is the clock tick interrupt handler that counts sleeps and timers down and gets the thread scheduled when it gets ready to run again. Their sleep/wait time is adjusted when the system clock gets re-calibrated by a time server.
I am working on UDP Server/Multiple Client Application.
There are multiple threads handling multiple clients.
There is one single thread which keeps on sending KEEPALIVE Messages to each active clients. Since this thread is in while(1) so CPU Usage reaches to 100%.
Since I want this functionality to go on, I have used a while(1) thread. I also tried adding a sleep after each execution of while but I don't think sleep() frees the CPU. Is there any way I can decrease CPU Usage for a specific time. e.g after a single execution of while, I can free up the CPU for like 10 secs and then continue back to while.
Please help me. Thanks a lot in advance.
sleep - Suspends the execution of the current thread until the time-out interval elapses.
And gives processor to other threads which are ready to run.
source : http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspx
So, just sleep does it all you need.
Sending keep-alive messages inside while(1) loop is bad idea because not only you burn all the CPU time but you also flood the network and storm the recipients of those messages. You can use Sleep() WinAPI function with a reasonable delay (10 seconds you suggested look reasonable) to suspend your sending thread for a while:
while( 1 ) {
sendKeepAlive();
Sleep( 10 * 1000 ); // 10 seconds
}
Sleep() definitely does suspend your thread and while the thread is suspended it doesn't consume CPU time.
instead of sleep try int usleep(useconds_t usec);
http://pubs.opengroup.org/onlinepubs/7908799/xsh/usleep.html
For windows specific you can give a try to timeBeginPeriod / timeEndPeriod.See the link – http://www.geisswerks.com/ryan/FAQS/timing.html
On Linux I use nanosleep() and then sleep(): nanosleep(&tsleep,NULL); sleep(1500)
int period=100000;
int limit=300;
struct timespec twork,tsleep; //time to work, and time to sleep
twork.tv_sec=0;
twork.tv_nsec=period*limit*1000;
tsleep.tv_sec=0;
tsleep.tv_nsec=period*limit*1000;
For c programming, if i want to coordinate two concurrently executing processes, I can use sleep(). However, i heard that sleep() is not a good idea to implement the orders of events between processes? Are there any reasons?
sleep() is not a coordination function. It never has been. sleep() makes your process do just that - go to sleep, not running at all for a certain period of time.
You have been misinformed. Perhaps your source was referring to what is known as a backoff after an acquisition of a lock fails, in which case a randomized sleep may be appropriate.
The way one generally establishes a relative event ordering between processes (ie, creates a happens-before edge) is to use a concurrency-control structure such as a condition variable which is only raised at a certain point, or a more-obtuse barrier which causes each thread hitting it to wait until all others have also reached that point in the program.
Using sleep() will impact the latency and CPU load. Let's say you sleep for 1ms and check some atomic shared variable. The average latency will be (at least) 0.5ms. You will be consuming CPU cycles in this non-active thread to poll the shared atomic variable. There are also often no guarantees about the sleep time.
The OS provides services to communicate/synchronize between threads/processes. Those have low latency, consume less CPU cycles, and often have other guarantees - those are the ones you should use... (E.g. condition variables, events, semaphores etc.). When you use those the thread/process does not need to "poll". The kernel wakes up the waiting threads/processes when needed (the thread/process "blocks").
There are some rare situations where polling is the best solution for thread/process synchronization, e.g. a spinlock, usually when the overhead of going through the kernel is larger than the time spent polling.
Sleep would not be a very robust way to handle event ordering between processes as there are so many things that can go wrong.
What if your sleep() is interrupted?
You need to be a bit more specific about what you mean by "implement the order of events between processes".
In my case, I was using this function in celery. I was doing time.sleep(10). And it was working fine if the celery_task was called once or twice per minute. But it created chaos in one case.
If the celery_task is called 1000 times
I had 4 celery workers, so the above 1000 celery calls were queued for execution.
The first 4 calls were executed by the 4 workers and the remaining 996 were still in the queue.
the workers were busy in the 4 tasks for 10 seconds and after 10 secs it took the next 4 tasks. Going this way it may take around 1000\4*10=2500 seconds.
Eventually, we had to remove time.sleep as it was blocking the worker for 10 seconds in my case.