I need two users on web page both have different actions and login so I am using two threads (Login--action--Logout)
now I want user2 to start after user1 has completed 100 requests and user1 is still continuing 101,102,.....
how do I do this?
I think I cannot use delays as sometime 100 requests may take 100 sec or 90 sec etc.
is there any way to start another thread in between the running of present thread
If you're using two different users with two sets of actions that should be done at two different times, it sounds to me like you want to use two different Thread Groups. Make sure to use Run Thread Group Consecutively.
Related
I have load testing scenario where test-plan has multiple thread-group and each thread-group has different type of HTTP request and this group is designed to executed in sequence .
Below is scenario I'm testing -
Test-Plan
+---Thread-Group(Register-Request)
+---Thread-Group(Container-Request)
+---Thread-Group(Subscription-Request)
+---Thread-Group(Data-Request)
+---Thread-Group(Deregister-Request)
Load testing has to follow the defined sequence. Each user-thread reads thread specific values from CSV file and during testing, JMeter output shows that:
User-threads don't move from Thread-Group(Register-Request) to Thread-Group(Container-Request) until all user threads have completed execution which looks odd to me.
Any idea what could the reason of this behaviour ?
User threads don't "move" from one Thread Group to another Thread Group, each Thread Group has its own pool of virtual users and they're not connected by any means.
So if you want each user to execute some actions (Register-Request, Container-Request, etc.) sequentially - you need to put the relevant Samplers under the same Thread Group.
If your workload model is more complex and i.e. you need to run different scenarios with different throughputs and maintain user session across Thread Groups at the same time - you can take a look at i.e. Using JMeter Variables With Multiple Thread Groups article Inter-Thread Communication Plugin or
I have one scheduled cron job (at the momment) runs every 5 minutes, the process looks for messages into database (oracle) with status "error" and then it gets all elements to continue in determinate flow (I am working with Mulesoft's Mule Runtime), I think if the process runs in two or more nodes it will reprocess two or more times, because the first node can get 10 registers and the second node also can get the same 10 registers and both of two process will send the same elements two times.
Is there a way to avoid this functionality? What is the best practice in this cases? Should I find another solution?
Please help me with this.
I've a application, need to use windows service with multiple threads to read 100 task record from SQL server table or mongodb collection, once a thread finish to read the 100 task, it must to set the status from 0('not processing') to 50(means 'processing'), then the thread will do some business logic, once it's done, then update the status from 50 to 100(means 'DONE') OR -1(means 'error encountered'). My question is how to prevent several different threads to read the same 100 records from table if I choose not to use the lock?
It's very simple. Just pick a reasonable number of records to process in a pass. Say you have 53,000 records and you choose 250 as the number to do per pass. That means you have 212 work units that need to be done and you can number them from 0 to 211 inclusive. Work unit N includes records 250*N to 250*N+249 inclusive.
Now the problem reduces to giving each thread an undone work unit to do. So long as all work units are done and no two threads attempt to do the same work unit, no database locks are needed.
How you assign the work units to threads is language specific. But the simplest way is to use some kind of a thread pool and dispatch each work unit to that thread pool.
I am trying to load multiple users from different ThreadGroup who are suppose to hit 3 different URLs at once with following scenario:
Test Plan
Synchronizing Timer (Number of simulated users to group by is: 100)
ThreadGroup 1(40 Users)
ThreadGroup 2(20 Users)
ThreadGroup 3(40 Users)
Is the above scenario correct to proceed with Synchronizing Timer as common timer with Total count of all ThreadGroup Users i.e: 40+20+40=100?
Help Appreciated!
If you want your 100 Users to hit the server at nearly exactly the same time then yes.
Note you would end up having very short delay between each set of 100 hits.
So you need to be sure this is realistic.
If you only want to simulate 100 Users running 3 types of URLs then there is no need for Synchronizing Timer here, use other timers like Gaussian Random Timer for example.
So to explain my situation:
I have a JMeter test plan that runs some test groups constantly in a loop. In addition to this I need to have multiple sampler requests go through together each minute (to simulate spiked usages). I can't set a constant timer to delay each of these because some may finish up quicker than others and they won't be in sync.
Is there a way to make multiple test groups send a request every minute the test is running?
OR
Is there a way to put all these samplers in 1 thread group and make them all run concurrently?
As far as I'm able to understand your use case, you need 2 Thread Groups.
First Thread Group which is SOAP Sampler A
Second Thread Group which is SOAP Sampler B
Then you need to set different variables for both thread groups to make them behave according to your use case and implement spikes you need.
Important: make sure that "Run Thread Groups consecutively" under your test plan is UNCHECKED elsewise you'll be having SOAP Sampler B running after SOAP Sampler A, not in the same time.
Lets consider your scenario is,
5 Users hitting 5 URLs(samplers) simultaneously.
So what you need to do is, in your Test Plan, add 5 Thread Groups. In each Thread Group configure the number of Threads to 5 and Ramp Up to 0.
Now, add one HTTP Request sampler in each Thread Group. Configure each sampler according to the URL you want to test.
Add Listener(s) to your Test Plan. Save the Test Plan and Run your test.
Make sure you haven't selected the "Run Thread Groups consecutively" in the Test Plan.