I'm using Jmeter 2.13 and something interesting is happening for which I need some help. I did two test on website with settings
test 1
users: 500
ramp up time:60
result:smooth connections
test 2
users: 500
ramp up time:120
result: crashes java
All I know is the Apache java GUI crashes. I don't know how to troubleshoot what's causing the crash. I know there are some elements with GUI you can configure to observe Jmeter server health stats i.e threads, load etc.
Also, on the settings where it crashes, a single request is made every 0.24 seconds.
On test case 1 where it worked this equates to 0.12 seconds a single request is made.
If the calculations are correct, theoretically speaking, it shouldn't crash right? (because the difference in negligible)
The answer is simple: don't use GUI mode to run a JMeter test. Ever. Use GUI only for test development and debugging.
Running JMeter in non-GUI mode is fairly simple:
jmeter -n -t /path/to/your/testplan.jmx -l /path/to/resultsfile.jtl
Once test finished you can open resultsfile.jtl with your favourite listener and analyse test results.
For more JMeter-side performance tips and tricks see JMeter Performance and Tuning Tips guide.
Related
When I run a JMeter Test Plan (jmx file) which comprises a single Thread Group that makes a SOAP request running 50 threads using a LoadRunner Controller the test runs perfectly, and I can achive 45 TPS consistently. This validates that the JMeter test plan and associated property files is uses are working perfectly under LoadRunner.
When I run the same test with JMeter the throughput drops over the course of the test run, reaching maybe 5 TPS after 15 minutes.
JMeter has maximum resources, and the developers have confirmend that the backend is processing as expected, the only difference seems to be how JMeter handles the requests, and how LoadRunner does as they use the same JMeter jmf file, data files, and property files for each test.
Can anybody suggest what the limiting factor can be for JMeter as LoadRunner runs the same test without suffering from decreasing throughut when everything else is identical test wise.
Thanks in advance,
NWC
Well-behaved JMeter doesn't have any limitations, just make sure to:
Follow JMeter Best Practices
Make sure that JMeter has enough headroom to operate in terms of CPU, RAM, etc. as if there is a lack of hardware/software resources JMeter will not be able to send requests fast enough. If you don't have any better monitoring solution you can consider using JMeter PerfMon Plugin
Pay attention to JVM metrics as well, ideally heap occupation should be between 40 and 70% otherwise you will suffer from too frequent/long GC events/chunking
Check out Concurrent, High Throughput Performance Testing with JMeter article for example JMeter-side performance bottlenecks analysis and JMeter tuning tips
We are using Apache JMeter (latest version) for load tests of a high performance API. JMeter response time is too high in comparison to SoapUI (free version). SoapUI gets an average response time of 200 milliseconds while JMeter reports at least 1200 milliseconds for the same API, testing from the same machine.
This affects the calculated throughput in each application. On SoapUI I can get up to 850 tps for said API, no errors. On JMeter I'm getting 190 tps at most, no matter what.
Tests are running with 200 threads, for 120 seconds.
I have already tweaked jvm/jmeter heap mmemory, garbage collector, and so on to no avail. Nothing changes. Can anyone help with this? Thank you.
Edit: Added test setup sample images
JMeter Thread Group and Test Plan Overall Setup
SoapUI TestSuite and Overall Setup
Edit 2: test results
Jmeter test results 1105 ms
SoapUi test results 263 ms
I can only think of one possible reason: you're running JMeter in GUI mode and this is not something you should be doing as JMeter isn't capable of sending requests fast enough, JMeter's GUI mode is designed for tests development and debugging.
Your images don't tell the full story as JMeter test results are missing. It would be also beneficial to generate a HTML Reporting Dashboard and see the correlation between increasing number of virtual users and response time/throughput.
And last but not the least, JMeter can be executed in Distributed Mode and in SoapUI it's available only for LoadUI Pro
I know load tests should be run in non-GUI mode.
But when I run the tests with the following command:
jmeter -n -t server_load_test.jmx -l log_100u_5s_01.jtl
In non-GUI mode:
I get an average response time between 3 or 4 seconds which of course is not acceptable.
In GUI mode:
I get an average response time of 100ms.
The test is really simple, it is just an HTTP request (GET) with 100 users in 5 seconds.
I would not have said anything if it was the other way around.
Which one should I trust?
My question is more: what is going on and how do I find the problem?
Non-GUI mode consumes a way less resources that GUI mode so I would recommend looking not only into Average Response Time, but also keep in mind other important metrics, for example check delivered load in both scenarios, i.e:
Active Threads Over Time and Transactions per Second listeners output (both are available via JMeter Plugins project
Generate HTML Reporting Dashboard and compare the output for both scenarios
Use 3rd-party analysis solution like JAnalyser or BM.Sense
My expectation is that in GUI mode you have much slower ramp-up hence you can run into the situation when some threads already had already finished their work while others were not yet started. In non-GUI ramp-up is faster so you have more online users so the load delivered to your application under test is much higher.
Try increasing loop count and test duration to see how it goes.
I am using JMeter for load testing. I have simulate 1500 users with loop count 1. But JMeter stops sending request after 1388 users. I wait for 3 hour but user didn't get increase.
also i am able to access the site under test from another system when JMeter stops sending request, it means server is not under load.
First of all, run JMeter in non-GUI mode as
jmeter -n -t /path/to/your/testplan.jmx -l /path/to/testresults.jtl
Second: disable all the listeners during test run. After test execution completion you will be able to open testresults.jtl file with the listener of your choice and perform analysis
Third: follow recommendations from JMeter Performance and Tuning Tips fuide
Finally: if you will be still experiencing problems it means that you went above your load generator machine hardware limits and need an another machine(s) to run JMeter in distributed mode.
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 :)