My application will take jmx file as test plan from user and execute it. I've JMeter distributed setup at the backend of my application (1 JMeter client and multiple JMeter servers).
The challenge I'm facing is with the #threads required to execute the test plan.
If I take #instances (JMeter servers executing the test) and #threads explicitly from the user, how do I configure user-provided test plan with this Thread-group before execution? This will allow me to verify these values with my cluster and machine capacity beforehand.
I had read about Include Controller, but that necessarily requires user test plan to have Test Fragment.
If not explicit, how do I verify the Thread group configuration in user test plan? Suppose, user has put large #threads in the test plan that could overload my JMeter server machine, how do I verify this value and probably warn the user to limit the #threads?
There is no such a thing as "#threads_per_instance" in JMeter world, if you run JMeter in distributed mode each server (or slave or load generator) executes .jmx test plan provided by the client as it is so if user uploads file with 100 threads in a Thread Group and you have 1 slave - you will have 100 users. If you have 2 slaves - you will have 200 users, etc.
Another thing is that you cannot tell how many threads you will be able to simulate from a single JMeter slave beforehand as it mainly depends on the nature of the test: request/response size, number of pre/post processors, assertions, listeners, etc. I would recommend implementing some form of JMeter slaves health monitoring and warn the user if CPU or RAM or Network usage starts exceeding 80%. It can be easily achieved using JMeter PerfMon Plugin
We don't know what technologies are being used in "your application" so this question is too broad. JMeter .jmx scripts are just XML files so you should be able to use XML parser to extract the number of threads in all Thread Groups and "validate" it somehow.
Related
Can we perform load tests on EPP applications? The application is a Windows batch file that interacts with the server. Which performance testing tool would be suitable for use? I need some help with this.
The key point is "interacts". If your goal is to simulate hunderds/thousands of Windows machines concurrencty running the batch file the easiest way would be replicating the network traffic generated by these .batch files so you could replay it at scale.
So you need to analyze the network protocol(s) which is(are) under the hood of the batch file used for communication with the server and check if the network footprint can be simulated using JMeter's built-in Samplers or JMeter Plugins, if the protocol communication can be replayed - you can just increase the number of threads (virtual users) in JMeter's Thread Group to simulate multiple simultaneous batches execution.
If batch file uses HTTP protocol for interacting with the server - you will be even able to record the traffic using JMeter's HTTP(S) Test Script Recorder, see How to Run Performance Tests of Desktop Applications Using JMeter article for more details.
It is also possible to kick off multiple batches instance using OS Process Sampler but in this case you won't get reasonable metrics and KPIs
In continuation with this ques - Modify Thread Group of an external JMeter Test Plan (JMX File)
My application will take jmx file as test plan from user and execute it. I've JMeter distributed setup at the backend of my application (1 JMeter client and multiple JMeter servers).
Is there a way to control/limit the RPS of this test plan?
Is there a way to modify RPS at runtime for this user-provided test plan (not created by us)?
It cannot be done without modifying the .JMX script.
RPS can be controller by adding i.e. Constant Throughput Timer or Precise Throughput Timer to the Test Plan and specifying the desired throughput there
RPS can be controller in the runtime by Beanshell Server, see How to Change JMeter´s Load During Runtime article for comprehensive explanation if needed
I am having a requirement in which I need to perform a testing with 1000 users by setting up slave machines. So I just want to know from 1000 users how many users will be taken by slave machine?
Is there any way to find out how many users have been taken by masters and slaves or if jmeter itself automatically distributes a load?
JMeter slaves execute the Test Plan which is being sent to them by the master so if you define 1000 users under a Thread Group - each slave will kick off 1000 threads.
Looking into Distributed Testing documentation:
Note: The same test plan is run by all the servers. JMeter does not distribute the load between servers, each runs the full test plan. So if you set 1000 Threads and have 6 JMeter server, you end up injecting 6000 Threads.
so be careful and try to not overwhelm the application under test
Master doesn't produce any load, it just configures the slaves and collects results (unless you launch a slave process on the master as well)
More information: How to Perform Distributed Testing in JMeter
My jmx file has 30 requests , 30 users, and response data may very according to the user logged. I am using view result tree as listener, my question is how to know for which user for which a request failed to get a response from server?
There are multiple options, to provide exact solution we need to know more details.
JMeter provides information about thread (virtual user) number as "Thread Name"
You can append the relevant JMeter Variable to the sampler name:
N.B. Don't use View Results Tree listener for anything but tests development and debugging as it is very resource intensive, when it comes to load test execution it will consume lots of the RAM and it may ruin your test. Run you test in command-line non-GUI mode and use listeners to analyse the results file after test completion. More information on JMeter tuning for the maximum performance: 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure
I have created a test plan for creating userprofile.
I want to run my test plan for 100 users but when i run it for 10 users then it is running successfully with rump up time of 2 sec; but when i try it for 100 users & more than that it is getting failed I am giving rump uptime of 40 sec for 100 users.
I am not able to understand what may be the problem with it.
In my test plan the thread user are differentiated with id
Thanks in Advance.
It's a wide question, this behavior can be caused by
Your application under test can't handle load of 100 threads. Check logs for errors and make sure that application/web server and/or database configuration allow 100+ concurrent connections. Also you can check "Latency" metric to see if there is a problem with infrastructure or application itself.
Your load generator machine can't create 100 concurrent threads. If so - you'll need to consider JMeter Distributed Testing
Your script isn't optimized. I.e. using memory-consuming listeners like "View Results Tree", any graph listeners, regular expression extractors. Try following JMeter Performance and Tuning Tips guide and see whether it resolves your issue.
Agree with Dmitri, reason could be one of the above three.
One more thing you can try.
You can run your jmeter in ui mode for validation of your script and after validation you can run it in non-ui mode which will save lot of memory and cpu processing (basically UI is heaviest part in jmeter).
you can run your jmeter script in non-ui mode like this,
Jmeter -n -t -H proxy -P port
generally on a single dual core machine with 2 GB ram (Load Generator in your case) 100 user test can be carried out successfully.
some more things you can look at to find out the actual bottleneck
1.check application server logs (server on which your application is hosted)
if there are any failures in that then see performance counters on server (CPU, Memory, network etc) to see anything is overloaded.
(if server is windows then check using perfmon if linux then try sar)
if something is overloaded then reason is your app server cant take load of 100 users
probably try tuning it more.
2.check load generator system performance counters (JVM heap usage,CPU,Memory etc)
if JVM heap size is small enough try increasing it but if other counters are overloaded then try distributed load testing.
3.remove unwanted/heavy listeners, assertion from script.
maybe this will help :)