I'm testing .NET application using JMETER, when ever I execute test with 300 vusers RAM consumption is more than 11GB. I also observed in JVisualVM that each vuser is taking more than 396MB, in fact its keep on increasing. Can anyone give solution how to execute with minimal RAM usage.
Thanks in advance.
You are most probably load testing in GUI Mode using a View Results Tree
Use NON GUI Mode:
http://jmeter.apache.org/usermanual/get-started.html#non_gui
And read:
http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
http://jmeter.apache.org/usermanual/best-practices.html
Related
I'm getting the following error:
out of memory error : java heap space error while running jmeter script for long run say 20 hrs.
I have set 10 GB heap size to run 10 threads only.
Could it be my application's bug? How can I be sure that this is application's bug not a jmeter issue?
JMeter is a Java application with a GUI. It also supports a non-GUI mode 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 threads.
Disable ALL Listeners during the Test Run. They are only for debugging and use them to design the 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.
Use Up-to-Date Software:
Java and JMeter should be kept updated.
Decide Which Metrics You Need to Store:
When it comes to storing requests and response headers, assertion results and response data can consume a lot of memory! So it is wise try not to store these values on JMeter unless it’s absolutely necessary.
JMeter SaveService badly configured: Check if you are saving requests and responses in your JTL.
For better and more elaborated understanding, this blog about 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure is helpful.
I am performing baseline performance test on a project. Average load time reported by jmeter is much higher than actual load time in browser(fresh- no cache and cookies).
What will be the issue?
I suggest to check the following:
Load generator overload. Re-run JMeter test with one user/thread and compare with Firefox. If the results will be comparable then the response time in JMeter may be excessive due to its overload. Try to address it by adding more load generators.
Inaccurate browser emulation. If even with one user the response time in the load test is higher, then it can be caused by inaccurate emulation of browser paralel connections. To troubleshoot it, compare waterfall diagrams. To get it from Firefox, use Firebug. Route JMeter traffic through Fiddler which displays the waterfall on the Timeline tab. If the waterfalls are different, you may have the following issue: a web browser downloads resources in parallel, while by default JMeter replays recorded traffic sequentially. To fix it, add these settings: Simulating browsers using JMeter.
Are you checking with browser during the load test ? or at another time ?
In the latter case, you would be comparing apples and oranges.
Are you using JMeter GUI mode ? if yes, it's a bad practice, GUI mode is for scripting, NON GUI mode for load testing:
http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
How much threads are you using ? and which version of Jmeter ?
For embedded resources testing, 3.0 is the most realistic and performing:
https://jmeter.apache.org/changes.html
Whenever you run performance tests instead of Average response times, always consider 90th percentile. In some cases avg. response time is skewed even if one request takes long to respond. So please check 90th Percentile.
If you are running the test with multiple users, try to hit the application from browser while load test is going on and check the response time on browser. This will tell you if your observation is correct.
The load generator may not be able to establish enough connections due to which you might see higher response time. Check load generator utilization in case if you doubt. In some cases load generator itself can't generate enough load.
Check your sever utilization when you run the performance test. This will give you an idea if the application is not able to handle the load or if it's the issue with load generator.
If you are running tests from UI mode, please try to run tests with non-UI mode. (Can you specify with how many users you are running these tests?)
Increase JMeter memory if you see issue with load generator and keep eye on load generator CPU usage too.
Check if load generator and browser from which you are hitting the application are on the same network and check network latency to check if there is network problem.
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.
I have done load testing for 100 concurrent users for simple login scenario using Jmeter. But I am not in position to say where the issue exist from load testing results. What are the parameters do i consider in order to find out the performance issue from the results?
Please help me out.
In order to find a performance bottleneck triggered by a Jmeter test, you real need to monitor the target hosts themselves, looking at things like CPU usage, memory usage, heap space usage, etc. In addition, you need to evaluate the behavior of specific services that were invoked by Jmeter requests.
In other words, Jmeter can help you to create a load/performance/stress test scenario that will encounter performance bottlenecks in your application, but the analysis of the sources of those bottlenecks is really best handled as a separate system and application monitoring activity while the Jmeter test(s) are running.
I'm using JMeter to test a Java application written by a 3rd party vendor using Versata Logic Studio.
I've got some steps in my test plan that submit a request using some post data and then receive a response back:
Response too large to be displayed. Size: 445817 > Max: 204800, Start of message:
{"header":{"action":"300","arguments":{"tabid":"Header","divid":"ActgDisb,Vendor,BusinessType...ETC
This seems fine (I'm guessing that's 400K?), except that the step is taking far longer than it does to click through the pages in a browser. In the browser it takes 5 seconds at most. In JMeter it's taking 2 minutes. The CPU is also at 60% for just one thread during these steps.
Any ideas on speeding this up? We're struggling to get enough slaves going and this certainly isn't helping.
The message that is displayed tells that you are using View Result Tree during your load test. Jmeter sets a limit that can be changed on the size of pages displayed in this component by adding to user.properties file:
view.results.tree.max_size which defaults to 200 ko
BUT during a load test never ever use this component as it requires a lot of resources (memory and cpu). This component must only be used during scripting phase.
You can read this article that gives tips on JMeter configuration and tuning:
http://www.ubik-ingenierie.com/blog/jmeter_performance_tuning_tips/
Disclaimer : I wrote it and it's my company but IMHO I think it's worth reading :-)
Also read this:
http://jmeter.apache.org/usermanual/component_reference.html
If your JMeter script is using a lot of file I/O, then putting those files in RAM will significantly improve the speed. You can use any app such as IMDisk (freeware) to create a virtual disk in RAM. Make sure that you have more than 4GB RAM.
In our case, we are sending around 8000 small files per user. With 200 users on each system, Jmeter is reading 16 Lack files. This was the bottleneck. With the RAM Disk, the file read speed was increased by 20 times and it helped Jmeter to run at full speed.
If you're ready to move to TCP level, there is HTTP Raw Request that allows memory-efficient operation for huge uploads/downloads. Read its manual carefully, there is some JMeter properties for tuning its performance.
However, my experience is that you possibly have a situation where Java itself is a bad technology to perform load tests. I suggest you to take a pair of tries for Raw Request and in case of failure to seek for some C/C++ tool for performance tests.