I am using JMeter to simulate a user running our Android app. This app has several background threads that poll different services at different intervals. I'd like to test a large number of these types of users. Is there a way to do that in JMeter?
If "different intervals" come into play the only solution I can think of is using different Thread Groups for representing different services consumers as due to JMeter's threads model all Samplers inside a single Thread Group will act at a speed of the "slowest" sampler and given the application has "background" services these calls need to be non-blocking.
There are other approaches like using Throughput Controller, Weighted Switch Controller, etc. but they fall under the aforementioned limitation.
I may have figured it out. I use a combination of Parallel Controller, and nested within those are Loop Controllers with a Flow Control Action that pauses for the right number of seconds. I'll leave this question open for a bit in case anyone has a better recommendation.
See: https://github.com/Blazemeter/jmeter-bzm-plugins/blob/master/parallel/Parallel.md
Related
I have 250 users ,and around 60000 sample counts should be hit including all the requests. Whichever request is supposed to get huge sample count,I have put those request within loop count,But the requests outside the loop are getting executed only 3-4 times which is less than expected. How do I handle this?
It is not very possible to provide the comprehensive answer without knowing what you're trying to achieve and seeing your test or at least Thread Group configuration
The easiest option is moving the requests which you want to execute more times into a separate Thread Group
If the requests have to stay in one Thread Group you can control the frequency using Throughput Controller
If the logic is more complex - consider using Switch Controller or Weighted Switch Controller
I'm currently using Apache JMeter to run load tests on the REST interfaces of my backend application. The test plan currently uses two thread groups and runs those in loops. Both thread groups are sending particular REST requests at a certain throughput using a constant throughput timer. The first thread group randomly picks one of several different REST requests, while the other uses one fixed REST request.
With this setup, I'm able to fire load to my application at a constant throughput. Now, I would like to simulate that over a day/night load profile, given that from e.g. 8:00 am to 5:00 pm the load is at a certain constant throughput, while in the rest of the time (the night), the load drops to a lower throughput or even stops entirely. Then at 8:00 am the next morning, it rises again.
Do you guys know if such a load profile can be simulated using Apache JMeter? Do you also know, which constructs could be used to setup something like that?
Thanks for any hint.
Regards
Timo
You can consider switching to Throughput Shaping Timer which seems to be exactly what you're looking for. See Special Property Processing chapter for the "load profiles" bit.
You can get Throughput Shaping Timer element via JMeter Plugins Manager
I have created seven thread groups which execute different scenarios in one application. I'm trying to optimize my scripts in order to be more maintainable and easy to master when someone else uses them.
The thing that i cannot figure out is how can i combine those thread groups into one or two and to still have the seven different execution paths and the possibility to control them, by control i mean to set how many users to execute scenario 1, how many to execute scenario 2 etc. till 7.
Currently the test plan looks like this
If you don't want several thread groups for some reason the alternative options are in:
Throughput Controller - with different global executions or execution percentages
Switch Controller - which provides random weighted values (in some cases Throughput Controller doesn't guarantee that samplers in scope will ever be executed)
See Running JMeter Samplers with Defined Percentage Probability guide for more information on configuration and implementation.
Well i just figured out how to do that i have added a Loop controller a Random Order Controller as child of the loop controller. And i have put seven throughput controllers as child of the Random Order Controller so now everything looks fine
I am trying to run http samplers sequentially for multiple requests. Where the output of 1 API response is the input of next API request. My concern is when I run with 5 users (for. e.g), then at given point of time it first executes 1st API with 5 users then second API with 5 users, in this process the API where input is required gets lost. Please help me on this. I need a solution, where all the samplers are first executed for first user, then for second thread all the samplers are executed and so on.
Dzizu is correct, threads are independent so you are going to run into problems with this approach.
Since you are using 5 users across the test, it would be better to have one thread group with 5 users, and then have Simple controllers (or Transaction controllers) that hold the HTTP samplers and whatever else you are using. This will ensure that the samplers are executed concurrently, but they can still share data if required.
Simple example below:
Threads usually are independent. The easiest way in my opinion is to put full process in one thread and then multiply threads in thread groups.
Eventually I tried to solve this by using loop count option. For example if I want to simulate 5 users in 1 second, I set values as loop count=5,threads=1,ramp-up=.2.
This worked for me so give it a try.
Use the Transaction Controller or Simple Controller to group your samplers together and run them in sequence without worrying about the number of threads. For me, it is working as expected :).
I am load testing (baseline, capacity, longevity) a bunch of APIs (eg. user service, player service, etc) using JMeter. Each of these services have several endpoints (eg. create, update, delete, etc). I am trying to figure out a good way to organize my test plans in JMeter so that I can load test all of these services.
1) Is it a good idea to create a separate JMeter Test Plan (jmx) for each of the APIs rather than creating one JMeter test plan and adding thread groups like "Thread Group for User Service", "Thread Group for Player Service", etc? I was thinking about adding one test plan per API, and then adding several Thread Groups for different types of load testing (baseline, capacity, longevity, etc).
2) When JMeter calculates the Sample Time (Response Time), does it also include the time taken by the BeanShell Processors?
3) Is it a good idea to put a Listener inside of each Simple Controller? I am using JMeter Plugins for reporting. I wanted to view the reports for each endpoint.
Answers to any or all of the questions would be much appreciated :)
I am using a structure like below for creating a test plan in JMeter.
1) I like a test plan to look like a test suite. JMeter has several ways of separating components and test requirements, so it can be hard to set a rule. One test plan is likely to be more efficient than several, and can be configured to satisfy most requirements. I find there can be alot of repetition between plans, which often means maintaining the same code in different places. Better to use modules and includes on the same plan to reduce code duplication, but includes are equivalent and can be used with test fragments to reduce duplication.
Threadgroups are best used as user groups, but can be used to separate tests any way you please. Consider the scaling you need for different pages/sites. ie User/Administrator tests can be done in different Thread Groups, so you can simulate say 50 users and 2 admins testing concurrently. Or you may distinguish front-end/back-end or even pages/sites.
2) It does not include beanshell pre- and post-processing times. (But if you use a beanshell sampler, it depends on the code)
3) listeners are expensive, so fewer is better. To separate the results, you can give each sampler a different title, and the listeners/graphs can then group these as required. You can include timestamps or indexes as part of your sampler title using variables, properties and ${__javaScript}, etc. This will cause more or less grouping depending on the implementation you choose.