I want to run the login thread group always first and wait for it to finish. And then in the same test plan run other thread group in parallel.
e.g.
Login-1 (always first )
Thread group-2 (after login in parallel)
Thread group-3 (after login in parallel)
Take a look at setUp Thread Group, as per description:
A special type of ThreadGroup that can be utilized to perform Pre-Test Actions. The behavior of these threads is exactly like a normal Thread Group element. The difference is that these type of threads execute before the test proceeds to the executing of regular Thread Groups.
More information: How to Use the SetUp Thread Group in JMeter
Below Test plan might help you.
Here first thread group is a setUP Thread Group which will be executed once, Rest are regular thread groups.
(You can run setUp Thread group with as many number of users and duration you want, other Regular Thread groups will wait until setup thread is completed)
On test plan level uncheck "Run Thread Groups consecutively"
Related
I am trying to understand the concept behind the threadpool. Based on my understanding, a thread can not be restarted once completed. One will have to create a new thread in order to execute a new task. If that is the right understanding, does ThreadPool executor recreates new thread for every task that is added?
One will have to create a new thread in order to execute a new task
No. Task are an abstraction of a logical work to perform. It can be typically a function reference/pointer with an ordered list of well-defined parameters (to give to the function). Multiple tasks can be assigned to a given thread. A thread pool is usually a set of threads waiting for new incoming tasks to be executed.
As a result, threads of a given thread-pool are created once.
I have the following scenario:
Run thread group a once at setup
Run a separate thread group b once at setup
Repeatedly loop requests in thread group c.
make all those threads that participated in groups b and c run thread group d
Make the thread that participated in thread group a run thread group e
How do I do this? It's number 1 and 5 that I'm not sure about, and how to make sure threads from a don't participate in c.
JMeter threads (virtual users) cannot go outside the Thread Group, once started, a thread executes Samplers upside down (or according to the Logic Controllers). When a thread doesn't have more Samplers to execute or loops to iterate - it's being shut down.
Threads are not going to the next Thread Group.
If you need to "pass" a thread from one thread group to another the only way of doing this is starting a brand new thread in another Thread Group and pass the "context" of the thread from the first Thread Group to the new thread, it may include:
JMeter Variables
Headers
Cookies
etc.
There are 2 approaches of passing the data between threads in different thread groups:
Convert the data you want to pass into JMeter Properties using __setProperty() function in the first Thread Group so set the value(s) and __P() function in the second Thread Group to read the value(s)
Using Inter-Thread Communication Plugin
There was a simple way to do this. Add a throughput controller in the same setUp group b. Make total throughput executions = 1. Done.
For example, let us assume that in my operating system a context switch to another process occurs after 100μ of execution time. Furthermore, my computer has only one processor with one thread of execution possible.
If I have Process A which contains only one thread of execution and Process B which has four threads of execution, will this mean that the thread in process A will run for 100μ and process B will also run for 100μ but split the execution time between each thread before context switching?
Process A: ran for 100μ
Thread 1 in Process A execution time: 100μ
Process B: ran for 100μ
Thread 1 in Process A execution time: ~25μ
Thread 2 in Process A execution time: ~25μ
Thread 3 in Process A execution time: ~25μ
Thread 4 in Process A execution time: ~25μ
Would the above be correct?
Moreover, would this be different if I had a quad core processor? If I had a quad core processor, would this potentially mean each thread could run for 100μ each across all processors?
It all really depends on what you are doing within the process / processing in each thread. If the process you are trying to run can benefit from splitting over threads, like for example, making calls to a web service for processing (since a web service can accept multiple calls at once and execute then separately), then no... the single thread will take longer to process than the 4 threads simply because it is executing the calls linearly instead of simultaneously.
On the other hand, if you are executing a process / code that does not benefit from thread splitting, then the time to finish all 4 processing threads will be the same on a single core.
However, in most cases, splitting the processing into threads should take less time than executing it on a single thread, if you do it right.
The matter of Cores doesn't factor in in this case unless you are attempting to run more threads than one core can handle. In which case, the OS will run the extra threads on a separate core.
This link explains a bit more the situation with Cores and Hyper-Threading...
http://www.howtogeek.com/194756/cpu-basics-multiple-cpus-cores-and-hyper-threading-explained/
Thread switches are always on the same interval regardless of process ownership. So if it's 100micro then it's always 100micro. Unless of course the thread itself surrenders execution. When this thread is going to run again is where things get complicated
I have a gearman job that runs and itself executes more jobs when in turn may execute more jobs. I would like some kind of callback when all nested jobs have completed. I can easily do this, but my implementations would tie up workers (spin until children are complete) which I do not want to do.
Is there a workaround? There is no concept of "groups" in Gearman AFAIK, so I can't add jobs to a group and have something fire once that group has completed.
As you say, there's nothing built-in to Gearman to handle this. If you don't want to tie up a worker (and letting that worker add tasks and track their completion for you), you'll have to do out-of-band status tracking.
A way to do this is to keep a group identifier in memcached, and increment the number of finished subtasks when a task finishes, and increment the number of total tasks when you add a new one for the same group. You can then poll memcached to see the current state of execution (tasks finished vs tasks total).
I have a simple UI that has two buttons 'Start' and 'Stop'. When user clicks 'Start' I have to perform a lengthy operation so I launch a worker thread to keep UI responsive. Now if user clicks Stop I need to stop the operation asap.
One way to implement this is that the worker thread function checks for a bool bStop = false every second and if user clicks Stop we set bStop to true from the Stop button handler and the worker thread stops the current operation.
Another way is to kill the thread using its handle.
Is there any better ways to do it?
You can have a look at the new Cancel functionality via TPL.
http://msdn.microsoft.com/en-us/library/dd997396(v=vs.110).aspx
It depends on your environment, #Coder777.
In general, job cancellation requires the job to be programmed to accept a cancellation request and clean-up appropriately to avoid partial failure states. In very few environments is it safe to simply kill the thread (these environments have been coded specifically to handle thread termination in an orderly fashion).
If the job is non-blocking, a flag can be checked at one or more stages within the job to determine if the job should be cancelled; and, gracefully terminate the job, cleaning up resources, etc., if it is cancelled. If the job can block, e.g., on IO, then you will need to ensure the block is interrupt-able and notify it asynchronously, or allow the block to periodically time-out and resume it's block after checking for cancellation.
See the following articles on how this done in Java:
How to stop a java thread gracefully?
How to properly stop the Thread in Java?
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousChannel.html