Customer has 2 scenario's. Both have more then 1 flow.
For example.
Tickets
a. Buy Tickets: 1500 concurrent users
b. Browse the website: 1500 concurrent users
View
a. Flow 1: 750 concurrent users
b. Flow 2: 750 concurrent users
c. Search the website: 500 concurrent users
Scenario 1 must be run before scenario 2 can be run.
Now is my question: how can I put this in Jmeter?
Normally you should use different Thread Groups to represent different groups of business users. If you need one Thread Group to be executed before the other(s) either go for setUp Thread Group or tick Run Thread Groups consecutively on Test Plan level, this way Thread Groups will be executed upside down
If you need yet another level of distribution inside the Thread Group you can use Throughput Controller which controls how often its children will be executed. So if you put 3 flows under 2nd Thread Group you can use:
2000 threads (virtual users) in total
Throughput Controller 1 - 37.5% of threads will be executing flow b
Throughput Controller 2 - 37.5% of threads will be executing flow c
Throughput Controller 3 - 25% of threads will be searching website
Example test plan outline:
More information: Running JMeter Samplers with Defined Percentage Probability
It's important to note that, although the mentioned techniques will work in terms of configuring the number of VUsers, they will not guarantee that the Avg TPS per requests will match the same proportion. I've mentioned this in another post:
"It's common a misconception when trying to achieve a targeted percentage of requests to instantiate Vusers in the same proportion. This only works if the Avg Response Time (ART) of each type of request is the same. It's very unlikely that, for example, the search request ART will the same RT as the registration request. As a consequence, after executing the test for a certain amount of time the actual proportion of requests (of each type) will be the different than the targeted request proportion."
Related
Scenario - System should able to handle 1000 simultaneous users logged-in, and 500 users also active at the same time in the system.
Normally you should use different Thread Groups for representing different groups of business users so just add 2 Thread Groups, one with 1000 "logged-in" users and another one with 500 users which are "active" (whatever it means).
Then add HTTP Request samplers to implement your users activities (you can even record and replay the test scenarios using HTTP(S) Test Script Recorder)
If you already have implemented these user flows and just want to divide 1500 users into 1000 and 500 doing different actions within the bounds of the singe Thread Group- put them under 2 Throughput Controllers
More information: Running JMeter Samplers with Defined Percentage Probability
I want to Baseline my application .It is having two transactions "Place Order" and "Add A Product To Favorites".. Both of these transactions follow the same navigation route mostly. For the - Place Order Business Transaction the steps are Land on Login Page .. Login..Add To Cart..Checkout..Place Order. For the - Add A Product to favorites Business Transaction, the steps are : Land on Login page..Login....Add To Cart...Add to favorites. I want to run Test and see the consistent response time the application gives at a particular throughput. I have the below queries.
If I create Add to Favorites scenario as a Thread Group with 4 samplers and Place Order Scenario with 5 samplers(as given by the steps mentioned ), should I add a throughput Shaping Timer separately for the individual Thread Group and if so what would be the Throughput parameters that I should give like RPS settings.
My application has the following Max response time and avg response time for a normal Load(i.e with no queue wait time since I collected the response times by just running a single thread so that the Wait time component is Zero) .N.B L I have not added the think time for simplicity sake and also the response times are bit too costly since the backend ERPs are legacy systems.
So, the Thread Group that I will create for "Place Order" has http samplers below with their respective response times for a 1 user load:
Land on Login page - 6074 ms (avg 4492 ms)
Login using Credentials - 2549 ms (avg is 631 ms)
Add To Cart - 1553 ms (avg is 304 ms)
Land on Cart page: 47044 ms (Avg: 15901 ms)
Place Order : 19126 ms (avg is 17110 ms)
Logout : 4801 ms (avg is 2706 ms)
Below are my queries:
With the above response timings what is the max throughput i.e Place Order transactions that I can achieve so that I can set that as the TPS parameter in the Throughput shaping graph plugin and then run a load test. Please can somebody explain the calculation process to arrive at that value.
The same samplers (i.e Land on Login Page and Login and add to cart ) is used in multiple Thread Groups like the Place order Business Scenario above and the Add A Product To Favorite Business transaction . So my question is, if different Thread groups are going to pound the same Login Controller Servlet/Add to Cart Servlet (my app is a J2EE app) so how to take that into consideration so that the queue generated for the Login sampler will not affect the TPS to be achieved by place order Business scenario and the other Business scenarios that use the login sampler transaction since we will be running both the Thread groups.(One for Place Order and One thread Group for Add to favorites) while running the Load test
How to set the concurrency for a Thread group; say the Place Order Transaction .I have this question since we need to know the max response time. Hence should I add the entire response times of all the samplers in the Thread group and multiply by the TPS that we calculated and divide by 1000 .Please explain the logic in this case too.
Nobody apart from you can answer, from your numbers we can state that 1 user is capable of executing 1 Place Order request in 19 seconds or 3 Place Order requests per minute. If you add one more user there could be 2 cases:
Response time remains the same. In this case you will be able to execute 6 requests per minute with 2 users, 9 requests per minute with 3 users, etc.
Respons time increases. In this case you will NOT be able to execute 6 request per minute with 2 users due to performance bottleneck.
Check out What is the Relationship Between Users and Hits Per Second? article for more details.
I don't think you should be measuring various business use cases separately, well-behaved load test should represent real-live application usage as close as possible and in reality it is more than possible than one user creates and order while other users are logging in. However if you explicitly need to test order creation separately you can perform login in setUp Thread Group and then pass the authentication context (in majority of cases it is a set of Cookies) to the main Thread Group where the order creation takes place using i.e. Inter-Thread Communication Plugin
You don't need to know response time, you need to provide enough virtual users in order to conduct the required load (given the application is capable of handling it), consider using Concurrency Thread Group which can kick off extra threads if the current amount is not enough for maintaining the desired throughput. It can be connected with the Throughput Shaping Timer via Feedback function.
Requirement: Load for a total of 100 users within an hour. Each user hits 3 different services different number of times at the same time.
for example: user 1 is going to hit service1- 3 times, service2- 5 times and service3 - 4 times at the same time. Same will be repeated for 100 users over 1 hour.
I have a thread with users-100, rampup time -60 (min). and then I am using parallel plugin and within that plugin created those 3 different sample requests. But I don't know how to configure the number of times, each of those service will be called per user at the same time.
Your test scenario doesn't make sense, normally 1 thread (virtual user) can hit only one endpoint at a time. The use when user executes 3 same requests to the same endpoint looks very suspicious as well. So I would recommend reconsidering your scenario and implement distribution using one of the following approaches:
Use different Thread Groups for different requests
Use Throughput Controller
Use Switch Controller
Use Weighted Switch Controller
If however I'm wrong and you're trying to implement some form of AJAX testing when requests are being triggered at the same time and in parallel - example test plan would be something like:
Below is the actual volume i need to achieve in 1 hour of my jmeter load test.
Required Request/second=0.14 (520/3600)
Hence i have Throughput shaping timer with Start RPS and End RPS as 0.14 for 3600 Sec.
i have 2 thread groups.
Thread group 1 has transactions- Launch and Login.
TG1
**Thread Group**
Launch
Login
Thread group 2 has Action1 and Action2 transactions.
TG2
**Thread group**
**Action1**
**Action2**
Having all these under one thread group ,i can achieve anticipated load using combination of No Of threads required and Throughput COntroller.
But here my requirement is ,i have transactions in different thread groups.
Can anyone tell my how can i distribute the throughput for two different Thread groups.
You should be able to apply the same approach as for the single Thread Group to any amount of Thread Groups.
Throughput Controller obeys JMeter Scoping Rules so if you place it to be as a child of the 2nd Thread Group - it will not have any impact on other Thread Groups
Also be aware that in some cases it's easier to use Switch Controller for requests distribution, check out Running JMeter Samplers with Defined Percentage Probability article for more details.
If you are targeting for specific number of requests per second the best approach is to use
bzm - Arrivals Thread Group
It automatically adjusts userload and maintains target RPS levels.
You are targeting 0.14 request per second that means 8.4 requests per minute so in arrivals thread group enter 8 arrivals per minute (It accepts only whole numbers so you can round off to 8 or 9)
Enter Rampup rate steps and maximum number of concurrent users (This helps to limit max number of users )
And inside the thread group you can use throughput controllers to control your transaction executions as shown in above screenshot.
Please refer to the sample test plan from the link ( you can find it in details section of the report).
I have concerns about the duration of executing JMeter Test Scenario.
In fact, if we execute a manual test with 1 user in 1 hour, we will find the same duration or little more with 3 user.
But, with JMeter test the duration with 1 user will be multiplied by the number of users.
During my scripting with this tool, I've noticed that JMeter always wait for the response of the request to pass to another request. It's like we have 1 user doing the work of multiple users.
Does any body have explanations about this issue?
Can we configure JMeter to perform like we have x users working in // ?
Depends how you are simulating users..
Each thread will wait for a response, but users are represented by different threads, and threads do not wait for each other to complete samples, they are independent.
If you are using threads in thread group to represent users (which is the intended usage), the threads will start concurrently and run independently, so you should see the 3 users complete in an hour, as with manual tests. If this is not happening, then you should check the resources used on the client running jmeter during single thread and multi thread runs. Or perhaps the bottleneck may be in the transport (ie bandwidth). All you have determined so far is that the bottleneck is prior to the server, you need to determine where it is.
It is also possible you have created a thread group for each simulated user. If this is the case you can set the groups to run consecutive or concurrent. The setting for this is on the Test Plan element at the very top of the tree. You want concurrent, so untick 'Run Thread Groups Consecutively'.
So it comes down to how you are simulating users.
In ideal world if you test your site with 1 user all set of actions completes in 1 hour. If you add another 100 users - still one hour, 1000 users - 1 hour.
In real world server response time increases with the number of concurrent threads. But it isn't something like
1 user - average response time 10ms
2 users - 20 ms
3 users - 30 ms
But
1 user - 10 ms
2 users - 10 ms
3 users - 10 ms
10 users - 11 ms
The whole idea of the performance testing is to determine the upper limit of server load and identify bottlenecks and issues which happen under the load so you could state something like: using this hardware and this configuration the application is capable of serving 500 concurrent users without serious delays. In case of 1000 users response time will be more than 15 seconds.
In regards to threads, JMeter thread starts, executes samples one by one for defined amount of loops and exits. It is applicable for each thread which are independent. Basic throughput control can be done via ramp-up and loops count (see Thread Group documentation on details)
More advanced load scenario definition can be done using following Test Elements:
Ultimate Thread Group - which provides easy visual way of defining ramp-up, ramp-down and time to hold the load
Constant Throughput Timer - to set desired load rate in requests per minute
Synchronizing Timer - to pause all the test threads and release them at the same moment to produce a "spike"