The stress test plan contains 5 threads, see below.
Lets consider a food booking app :
Thread 0 contains the prerequisites such as extracting the token which will be used by the remaining threads (1,2,3,4).
Thread 1 relates to the food menu.
Thread 2 relates to adding items to the menu and calculating the order price.
Thread 3 creates the order.
Thread 4 confirms the order.
Each thread requires the previous thread to be executed as it uses the response from the previous thread and I have been asked to run Thread 1,2,3,4 concurrently, but the fact is they cannot be run concurrently as
Thread 3 cannot be executed without actually executing Thread 2 and so on.
7.
Let me add a real-world use case:
A user is viewing the menu items
Concurrently, another user is confirming the order
Another user is adding items to the cart
Actually, all the operations are taking place concurrently, but no operation can be performed by skipping the previous threads.
How do I make changes to my script to accommodate such type of parallel stress testing?
Had to re-read your question a few times... I think what you are asking is can you run multiple "Thread Groups" ... the answer is yes, in your test plan you right-click and add multiple Thread Groups, each thread Group has its own user journey scripted.
As for dependencies between Thread Groups there are options for sharing variables. but you would likely need to work out your logic and write a little bit of groovy to ensure that the data flows correctly.
You could also look at "How to Use the Inter-Thread Communication Plugin in JMeter" on the BlazeMeter website: https://www.blazemeter.com/blog/how-to-use-the-inter-thread-communication-plugin-in-jmeter
Update: After Christian's formatting of the question, it appears that "threads 0-4" are describing a user journey. for example; user logs in, clicks menu, adds item x, goes to checkout etc.
This would be recorded in one Thread Group. Each call made would provide a server response that could then be parameterised and correlated, ensuring data is passed appropriately. The "concurrency" would come from ramping up multiple users "Threads".
For example; here in this screenshot, I have added a Thread Group that has 4 HTTP Samplers (the user journey). The Thread Group is then set to run 10 users, ramping up in 5 minutes (300 seconds), and runs for a duration of 3600 seconds (aka 1 hour).
Related
Lets say we have 2 thread groups, one has 10 threads, another one has 30 threads. I have unchecked "run thread group consecutively". In table results, we see response time of second thread group is more than first threadgroup users.
When threadgroups are arranged other way, it shows reverse. So, whichever is second thread group, its user showing response time more than what is there in first thread group.
When you unchecked the "run thread group consecutively", then both the thread group runs in parallel. Now, based on the number of thread they will send the requests. In your scenario, 2nd thread group has created 30 threads and start sending the request. Now, based on,after how much time the response will come, it is listed in the view result. So, you thread group have more thread and may be getting response faster then thread 1. But, thread 1 is also going to be listed in the view results as shown below;-
Option is unchecked, so parallel running:-
So,in short, if "run thread group consecutively" option is unchecked, thread groups will run in parallel else sequential.
Option is checked, so sequential running:-
Hope this helps.
Only one explanation comes to my mind:
You're running your test in GUI mode
You're running it in GUI mode with Listeners enabled
If above assumptions are correct JMeter is simply lacking resources in order to kick off that many threads and given JMeter is not capable of sending requests fast enough you're getting "false negative" results as JMeter spends time in GC trying to free up some Heap space in order to be able to operate.
So:
Make sure to run your test in command-line non-GUI mode
Disable all the Listeners, they don't add any value, only consume valuable resources
Follow recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure in order to configure JMeter for maximum performance
I am doing load testing for one ecommerce website. I am using Ultimate thread group.
Now I want to send per user only 1 request. So for ex: If 500 users then only 500 request should send. How can I achieve it using Ultimate thread group?
Why I want above because I am doing whole process like login, select product, add to cart and checkout. So it should do everything only once per user.
Your test design is a little bit flaky as given each user does login, select product, add to cart and checkout you will have at least 4 requests per user which gives 2000 requests in total (doesn't include embedded resources calls). You can use Transaction Controller to group these requests into one "workflow" however it won't limit actual amount of requests.
If you need to run your workflow by each user only once you may run into a situation when either load will be less than 500 concurrent users or test duration will be less than 30/60 minutes, see JMeter Test Results: Why the Actual Users Number is Lower than Expected
If you add more iterations each user will be executing your workflow more than once
Normally web test plan should look as follows:
Given each user executes test scenario steps and acting like a real user
Gradually increase the number of users unless application response time becomes too high or errors start occurring, whatever comes the first
Analyze results, identify the bottleneck, report your findings
Lets say the duration of the test is 1 hour. First user completes the workflow you had mentioned in the first 10 mins itself. What should happen after the workflow for the user? Should the thread be idle for the remaining 50 mins?
I think you should use the regular Thread Group with 500 threads and loop count as 1. Ultimate Thread Group is for duration based tests. You could use Once Only Controller as a workaround inside to do the action only once for the user. But it is an ugly approach.
You can use Throughput Controller.
The Throughput Controller allows the user to control how often it is executed. There are two modes:
percent execution
total executions
Percent executions
causes the controller to execute a certain percentage of the iterations through the test plan.
Total executions
causes the controller to stop executing after a certain number of executions have occurred.
Like the Once Only Controller, this setting is reset when a parent Loop Controller restarts.
I am have been exploring JMeter for the last couple of days. And I am try to achieve the following:
I am trying to create a load test for a service such that, in the first loop 'n' threads are created and in the second loop 'n+m' threads are created and in the third loop 'n+2m' threads, in the fourth 'n+3m' threads and so on. I did find many solutions here and I tried replicating them, but somehow it is not working for me. The test plan I created looks something like this:
Step 1: Add a user defined variable called USERCOUNT = 0
Step 2: Create a thread group. I have used __intSum to increment USERCOUNT by one and storing the result back in USERCOUNT for future reference.
Ideally what I am expecting here is, in the first loop one thread is created, in second loop 2 thread are created and in the third loop 3 threads are created. So in total there should be 6 thread created. However the results show up something like this:
Not sure if I am missing something silly or my approach itself is completely wrong. Any help from the community would be appreciated. :)
I believe what you are trying to do is impossible. When JMeter starts a thread group for the first time it initializes the number of threads.
What you are essentially trying to do is re-run the same test three times with different numbers of users each time. JMeter cannot re-run a thread group once started, it can only re-run ("loop") a thread in a thread group. It is not possible to add threads to a running thread group once the ramp up and threads are initialized. (Let me know if I should try to explain that further).
If you want one thread group to populate the run-time settings of another thread group, you must have two thread groups in the test plan. At the test plan level, check off the option "Run Thread Groups Sequentially."
With that option, JMeter will not initialize the number of threads on the second thread group until the first one finishes. The first thread group can set a global property, and the second thread group can reference it in the number of threads.
How to set a property in beanshell: (this would be in Thread Group 1)
props.put("threadgroup_2_num_users","15");
How to reference that value in Thread Group 2:
${__P(threadgroup_2_num_users)}
If this does not help, maybe try to describe your end goal. What are you trying to learn about the thing you are testing?
Edit: Perhaps using the plugin package "Stepping Thread Group" will allow you to achieve the scenario you are trying in a single thread group. Check this out:
http://jmeter-plugins.org/wiki/SteppingThreadGroup/
JMeter currently doesn't provide possibility to change number of threads on-the-fly during test execution so I would suggest to go with the following alternatives:
Use i.e. Ultimate Thread Group available via JMeter Plugins which adds some extra features to JMeter's Thread Group so you will be able to implement your scenario
Consider so called "goal oriented scenario" when load is based on requests per second rather than on number of virtual users. You can precisely set desired throughput rate and even change it during test run using Constant Throughput Timer
I have entered 500 to be the number of thread group and ramp up time to be 120 seconds but when the report is generated,the virtual users count is only 15 or in composite graph-active threads over time is raised to near about 12. So I am bit confuse active threads counts. Because the data(threads) or numbers that I filled in test plan before test is different and after result is different. What about scaled values in graph?and x10?Something related to threads?
Each JMeter thread representing a virtual user after initialization starts executing samplers upside down (or according to the Logic Controllers).
If thread doesn't have more samplers to execute and no more loops to iterate it's being shut down. It looks just like your case. See Max Users is Lower than Expected article for more detailed explanation and workaround.
Usually people set Loop Count to "Forever" and use Runtime Controller to so test could finish in designed time. Another option is using i.e. Ultimate Thread Group available via JMeter Plugins which provides convenient way of defining a load scenario.
I have created a test plan with multiple thread groups that I want to execute simultaneously.
One group (A) involves tagging a folder with 1000 images in it, so it takes approx 10 seconds to respond.
The other group (B) is real quick.
What I've found is that group B seems to "stick" and wait for thread A to complete. Now all the reading I've done says that thread groups should be totally independant, but this doesn't seem to be the case in my test plan.
I have an HTTP defaults manager, cookie manager and user defined variables that are shared between groups (but have tried adding them in the separate thread groups).
Anyone got any idea why this should be?
Script is here: https://www.dropbox.com/sh/fhdof4ynjt73s2p/mkrphWcfHK
(likely will not run or stick though as this uses internal URL's)
This issue is not in JMeter, it is the application that is locking.
Looking at your test, you seem to use one user to do your load test, this clearly explains your issue and makes your test unrealistic as you have around 20 Users logged with the same user/password.