Would you please tell me the max limit of no. of threads that i can use in JMeter 2.4 for conducting a load test?
Is there any difference in taking all threads in a single loop or by taking less no. of threads and initialize loop to achieve same no. of users/threads?
Example:
No. of threads=500
Ramp up=1000
Loop=1
whether it is same as
No. of threads=50
Ramp up=100
Loop=10
or is there any difference in terms of result?
The max number of threads is determined by a lot of factors, see this answer https://stackoverflow.com/a/11922239/460802
There is a big difference in what you are proposing.
In theory you get the same number of results (500), but you are hitting the server in a very different manner.
Maximum number of users depends of your OS,free RAM and connection. Win XP is limited to 3000 processes at the same time. On Linux is more than 3000 but I don't how much. Be careful that you test server and if you start 3000 thread on your machine require a lot of resources and the test will not be real. I pref fare to start maximum 300 users per machine. If you want to increase the number of users than use distributed testing (use more machine as DoS attack). In theory is the same number of request but the time complexity is not the same.
This is very common to stuck here after creating a scenario and test cases, we need to run using JMeter and we have to fix the value of how many users or threads are allowed to use in JMeter Thread Group. We don't want to throttle either our Load generator or our JMeter instance.So basically, it is needed tweaking in both cases.Otherwise, The output of the test will be worthless and we will lose hours of our time. So here are the things we need to consider:-
HEAP=-Xms512m –Xmx512m
It means default allocated heap size is minimum 512MB, maximum 512MB. Configure it as per your own PC configuration. Keep in mind, OS also need some amount of memory, so don't allocate all of you physical RAM.
NEW=-XX:NewSize=128m -XX:MaxNewSize=512m
This means memory will be increased at this rate. You should be careful, because, if your load generation is very high at the beginning, this might need to increase. Keep in mind, it will fragment your heap space inside JVM if the range too broad. If so, Garbage Collector needs to work harder to clean up.
JMeter is Java GUI application. It also has the non-GUI edition which is less resource intensive (CPU/RAM). If we run JMeter in non-GUI mode, it will consume less resource and we can run more thread.
Disable ALL Listeners: During the Test Run. They are only for debugging and use them to design your desired script.
Listeners should be disabled during load tests. Enabling them causes additional overheads, which consume valuable resources that are needed by more important elements of your test.
Always try to use the Up-to-date software. Keep your Java and JMeter updated.
Don’t forget that when it comes to storing requests and response headers, assertion results and response data can consume a lot of memory! So try not to store these values on JMeter unless it’s absolutely necessary.
So in summary, if no Listeners are included in JMeter script, no monitoring inside running JMeter server, network overhead/barriers and JMeter scripts are optimized then here is a rough calculation:
The total number of concurrent user = (total allocable memory)/(Size of all requests)
You have to estimate your concurrent number user/thread (active threads) only in terms of your load scenario.
Also, you need to monitor whether your servers Memory consumption, CPU usages are running below 80 % or not. If these usages exceed 80 % consider those tests as unreliable as a report.
For better and more elaborate understanding these two blogs How many users JMeter can support? and 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure must help.
1: Of course it depends a lot on the machine running JMeter, but if mileage counts I can give you some hints. JMeter allows you to run multiple processes in the same box, and it's usually pretty reliable generating up to 200 threads per JMeter instance. If you need more than that, I'd recommend using multiple JMeter instances. A modern machine with some tweaking can easily generate 500 to 1000 threads. Using Linux you probably need to increase the max number of file descriptors (see here).
It helps a lot to run JMeter without a GUI, writing report/graphics data in a file to be rendered later. You must also pay attention to your networking limitations. It'd be easy for a server within a Gbps network to generate some thousands of requests, but a laptop sharing a 54 Mbps router would be much more limited. Try to divide your actual connection to the server by the size of the requests, and then you'll know if bandwidth will limit you. Pay special attention to JMeter's configuration to download or not the files referenced in an HTML response.
Hope I was able to help.
2: It's precisely what BlackGaff explained: "500 threads, Loop 1 " Means 500 threads AT THE SAME TIME doing the loop ONCE. "50 threads, loop 10" Means only 50 threads AT THE SAME TIME doing the loop TEN TIMES.
There is no limit on Thread execution in Jmeter. Since its a java based tool, it uses java thread capabilities. In case of concurrent thread execution we need to taken care of machine configuration (ie. Memory size and CPU).
To avoid OutOfMemory issue try to run jmeter in NON-GUI mode with custom java runtime arguments in jmeter script inside apache-jmeter/bin/jmeter .
Default is 512 MB.
I don't think there is any thread limit on JMeter itself if your machine can handle it. The basic idea of testing should be that, the switching of thread and waiting time should not affect the actual performance metrics too much.
There is huge difference between the two cases. In the first case, worst scenario, you will have 500 concurrent users. In the second case, the max number of concurrent users will be 50. The average time for scenario 1 will be larger than the average time for scenario 2.
