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
Related
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.
Could someone help me to understand the Difference of running the load testing using local System and setting up master-slave system ? How it differs ? what is the best practice to do load testing on server.
If we are setting up master-slave do both should be in same sub-network ?
And we can generate the HTML report in Master system after running the script?
The number of virtual users you can simulate on one machine varies from several hundreds to several thousands (check out What’s the Max Number of Users You Can Test on JMeter? article for more details) but in any case it is limited.
Each thread (virtual user) has some "footprint" in terms of CPU, RAM, Network and Disk usage. So you need to ensure that the machine you're running JMeter on has enough capacity and it's not overloaded because if JMeter is not capable of sending requests fast enough - you will get false negative results because throughput will be low not due to the application under test problem, but due to the problem with JMeter.
So make sure to monitor essential OS health metrics like CPU, RAM, Network, Disk, Swap usage when you're running a load test. You can do it using i.e. JMeter PerfMon Plugin
If you're able to conduct the required load using only single JMeter machine - running the test in distributed mode doesn't make a lot of sense as you will not get any new results.
However if one machine cannot produce the required load - you will have to conduct distributed testing. The main idea is having multiple JMeter instances executing the same Test Plan.
For example if you identified that you can run only 1000 virtual users on one machine and you need to simulate 3000 ones you will need 4 machines for this.
Master machine to orchestrate the slaves and collect the results
3 slave machines each running 1000 virtual users.
Once you start JMeter Serve ron each slave machine you will be able to run your test in command-line non-GUI mode as follows:
jmeter -n -t your_test_plan.jmx -R IP.of.1st.slave, IP.of.2nd.slave, IP.of.3rd.slave -l result.jtl
if you want to generate HTML Reporting Dashboard after the test run you can do it as follows:
jmeter -n -t your_test_plan.jmx -R IP.of.1st.slave, IP.of.2nd.slave, IP.of.3rd.slave -l result.jtl -e -o /path/to/output/folder
I have configured the script with below configuration for the distributed load testing. Now, when I executed the script. The dashboard report which was generated: Active Threads Over Time show x-axis "Number of Active Threads" to be 25 only. But according to the distributed testing setup if load testing is to performed for 50 users than on the master machine the thread is to configured to be 25 to run 25 each on the slave machines
Now, the problem here is why didn't Active Threads Over Time show x-axis "Number of Active Threads" to be 50 rather than 25.
Master(My own machine)
2 slaves machines
Thread: jp#gc - Stepping Thread Group
Number of Threads: 25
So, to properly access the graph I would require to have Active Threads Over Time show x-axis "Number of Active Threads" to be 50 which included each slave machine active threads. How to achieve this.
As per Active Threads Over Time Listener documentation:
If you are doing distributed tests, you should name the thread groups like this in your test plan:
${__machineName()}_My Threadgroup name
So you need to use __machineName() and/or __machineIP() functions as the prefix or postfix for the Thread Group labels so JMeter Listeners could distinguish the sample results coming from different remote slaves.
Check out How to Perform Distributed Testing in JMeter for more information on remote testing including some tips and tricks like running specific samplers on specific machines, configuring/disabling encryption of traffic between master and slaves, etc.
Ubuntu: Execution was not ending properly before test completion
I have two questions
1) I am running 4500 users test from two machines (2250+2250). Duration of the test is 1 hr 30 min.
At the end test was not closing and it's not giving a consolidated summary in the console.
2) after closing the test by keys(ctrl +C). If I open the jtl report from the master system its showing 2250 users in the (Active threads over time) Lisner.
Using ctrl+c is not enough for terminating the running process.
End your test by executing the shutdown.sh (or bat depending on your environment) to signal the running process to properly and gracefully end its execution. See here: http://jmeter.apache.org/usermanual/get-started.html
Edit: you can use the stoptest.cmd|sh for forcing a stop.
Looking into your execution log file my expectation is that your are kicking off 9000 threads. When it comes to remote testing JMeter Remote Engines are absolutely independent so each engine is executing the Test Plan it receives from the master.
If you define 4500 threads in the Thread Group(s) it means that every JMeter slave will kick off 4500 virtual users.
The fact that JMeter doesn't respond to Shutdown event indicates the fact that JMeter engines are overloaded so they even cannot gracefully shutdown in a reasonable time. Make sure you have monitoring of at least baseline CPU and Memory stats of JMeter load generators to ensure that they have enough headroom to operate as if they will be lacking resources it will result in the increased response time (and impossibility to shut the test down as well).
So my recommendations are:
Make sure the load you deliver matches your expectations as I am under the impression you are delivering twice as many users
Make sure you have monitoring of CPU, RAM, Network and Disk capacity on JMeter load generators, you can use i.e. JMeter PerfMon Plugin for this.
Make sure you're following JMeter Best Practices and recommendations from the 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 :)