Application is deployed in 16GBVM. While running JMeter from dedicated system throwing Network socket exception for 300 users
When i changed application to 8GB dedicated system its is working for 500 users trowing some other java exception.
Will JMeter support VM? Will get similar results(response time, throughput) like dedicated system.
Thanks in Advance.
JMeter doesn't know anything about underlying software or hardware, it is pure Java application so its run inside Java Virtual Machine which is an abstraction layer on top of OS which in its turn the abstraction layer on top of hardware.
So given VM and real device have similar hardware specifications you should get the similar results. Just make sure you following JMeter Best Practices, to wit:
Run your test in non-GUI mode
Disable all listeners during test run
Use only those pre/post processors and assertions which are absolutely required
Tune Java Heap and Garbage Collection settings according to total amount of available physical RAM and your load pattern.
See 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article for comprehensive information and some JMeter tuning tips.
Related
I'm monitoring the connect time and latency to connect from jmeter machine while running in GUI mode and that is in within acceptable limit.
Should we strictly follow non GUI mode even though I can able to perform load test with GUI mode?
I'm targeting 250 TPS and able to achieve that ..I have increased my memory and monitoring CPU and memory of load generator is below 60%.
Should I go for non GUI mode ?
The main limitation is that each event in the queue is being handled by a single event dispatch thread which will act as the bottleneck on your JMeter side.
My expectation is that your "250 TPS" look like:
while it should look like:
So check how does your load pattern look like using i.e. Transactions per Second listener (installable via JMeter Plugins Manager)
Also check how does your JVM look like especially when it comes to garbage collection, it can be done via i.e. JVisualVM, most probably you will see the same "chainsaw" pattern
You don't need to follow JMeter best practices, but
you may encounter issues to achieve specifc goals (as TPS)
your machine can't execute GUI or have low resources
you execute JMeter using a script or build tool as Jenkins
Also it's better to be familiar with JMeter CLI (non GUI) and its report capabilities
JMeter supports dashboard report generation to get graphs and statistics from a test plan.
Also it will be needed for using distributed testing
consider running multiple CLI JMeter instances on multiple machines using distributed mode (or not)
CLI also useful for Parameterising tests
The "loops" property can then be defined on the JMeter command-line:
jmeter … -Jloops=12
I'm doing a jmeter test the test is on localhost . My testplan is to hit login and then another http request . The test is running and getting response . But when I run the same test again I'm getting different results. I'm doing it in GUI mode . Please help me I'm new to jmeter.
You're violating at least 2 main best practices:
JMeter's GUI mode is for tests development and debugging only, when it comes to test execution you must run JMeter in command-line non-GUI mode
Having load generator (JMeter) and the system under test on the same machine is not the best idea, both tools may be very resource intensive when it comes to high loads and at some point they will start fighting for the OS resources like CPU, RAM, Network and Disk IO, etc. so when it comes to the bottleneck identification you will not be able to tell for sure why response times are high or throughput is low as the reasons could be in:
JMeter doesn't have enough headroom to operate and cannot send requests fast enough
Application cannot respond fast enough due to lack of RAM or CPU overload
CPU is constantly switching the context from JMeter to the application under test and vice versa
I am running a test for testing if my application is able to handle 250 concurrent users or not.first time when I ran the test,results were fine and number of samples generated in aggregate report is also fine but when I am running the same test again,i am getting drastic changes in aggregate report.This time number of samples got reduced and also the response time got higher.Whereas cpu usage and memory usage is fine and database server performance is also good.For this I am using stepping thread group.
please help me to get rid out of it.
What about CPU and RAM usage on the host, you're running JMeter on? Make sure that:
You running JMeter in non-GUI mode
You have all the listeners disabled
You have only absolutely minimum of pre/post processors and assertions added/enabled
JMeter has enough JVM heap space (70-80% of your total physical RAM)
See JMeter Performance and Tuning Tips for detailed explanations and more JMeter configuration tricks
Depending on the logic your application has you might not be able to handle 250 threads on single machine (not enough computing resources RAM, NIC bandwidth etc) You haven't provided details about your machine utilization during the run test and Jmeter logs for any warnings or errors. Check that.
We had the same kind of issues when we were testing heavy application (with sessions and long user flows). Master-slave config can fully resolve the issue.
What will be the hardware configuration required to run concurrent of 10,000 user's load in jmeter through non-gui mode?
There is no exact answer for this, but in my experience 10,000 users on a single instance doing anything other than very basic work will be too many.
You should look into setting up distributed testing, so that you have many different injectors. Without knowing anything about your application, I would still want at least 10 instances.
This link should get you started: http://jmeter.apache.org/usermanual/jmeter_distributed_testing_step_by_step.pdf
If you have budget for it, any of the cloud based Jmeter services will make it a lot less painless. Blazemeter is one such offering in this area: http://blazemeter.com/
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 :)