During the distributed load test, some of the threads (of 1250 spread across 8 VMs) are having issues in following the redirection and fails at the assertions. This happens after some 30-40 mins into the test. If thread-x fails at a Y iteration, then all the following iterations are having the same issue.
The JVM size is increased to 6GB (VM has 8GB Memory). We tried to force reset the status of httpclient by setting the flag
httpclient.reset_state_on_thread_group_iteration=true
When visiting page-x it redirects to a login page, say page-x/login?returnUrl=%2f with the HTTP-302 code. The Assertion to the sampler check for the text "Please submit your credentials".
The script/test works just fine perfectly for 30-40 mins and at some point there are too many errors stating the assertion failed. Inspecting more on the treeview, the page-x responds with 302 as expected, but the assertion marks that as failed.
The expectation is that jmeter follows the redirection as it did in the first 30-40 mins duration.
However the redirect doesn't happen for some reason (it could be an issue with assertion / jmeter didn't follow the redirect at all for some reason), and this error occurs only during a load test at random time.
Has anyone experienced the same before and found a solutions?
Related
I am testing a web application login page loading time with 300 thread users and ramp up period of 300 secs.Most of my samples return response code 200.But few of them return response code 400,503.
My goal is to just check the performance of the web application if 300 users start using it.
I am new to Jmeter and have basic knowledge of programming.
My Question :-
1.Can i ignore these errors and focus just on timings from the summary report ?
2.If i really need to fix these errors, how to fix it ?
There are 2 different problems indicated by these errors:
HTTP Status 400 stands for Bad Request - it means that you're sending malformed requests which cannot be understood by the server. You should inspect request details and amend JMeter configuration as it is the problem in your script.
HTTP Status 503 stands for Service Unavailable - it indicates the problem on server side, i.e. server is not capable of handling the load you're generating. This is something you can already report as the application issue. You can try to identify the underlying cause by:
looking into your application log files
checking whether your application has enough headroom to operate in terms of CPU, RAM, Network, Disk, etc. It can be done using APM tool or JMeter PerfMon Plugin
re-running your test with profiler tool telemetry to deep dive into what's under the hood of the longest response times
So first of all you should ensure that your test is doing what it is supposed to be doing by running it with 1-2 users/loops and inspecting requests/response details. At this stage you should not be having any errors.
Going forward you should increase the load gradually and correlate the increasing number of virtual users with the increasing response time/number of errors
`
Performance testing is different from load testing. What you are doing is load testing.
Performance testing is more about how quickly an action takes. I typically capture performance on a system not under load for a given action.
This gives a baseline that I can then refer to during load tests.
Hopefully, you’ve been given some performance figures to test. E.g. must be able to handle 300 requests in two minutes.
When moving onto load, I run a series of load tests with increasing number of users/threads and capture the results from each test.
Armed with this, I can see how load degrades performance to the point where errors start to show up. This gives you an idea of how much typical load the system can handle.
I’d also look to run soak tests too. This where I’d run JMeter for a long period with typical (not peak) load to make sure the system can handle sustained load.
In terms of the errors you’re seeing, no I would not ignore them. Assuming your test is calling the same endpoint, it seems safe to say the code is fine, its the infrastructure struggling with the load you’re throwing at it.
I am doing a load test of 300 Virtual users on an application. Previously my users were ramping down and test seems to be finished with in time But now as I jump to 500 user test my users are not ramping down and test keep running for like infinite amount of time. Again I run the test with 300 users, 37 users are still in the system and are not ramping down. Hence my test did not finish.
These are the things that I tried to fix,
Increase the HEAP size in jmeter.properties file.
Cleared the cache and rebooted the services (i.e. SQLSERVER and
collab services)
Can anybody suggest that where Iam doing wrong?
It might be the case your server fails to provide response, by default JMeter will wait for the response forever, it might explain the situation you're running into.
There is "Timeouts" section on the "Advanced" tab of the HTTP Request sampler (or even better HTTP Request Defaults configuration element) where you can set maximum values for Connect / Response, in case if they are exceeded JMeter will automatically mark the sampler as failed and proceed.
Alternative options:
You can set maximum test duration using "Scheduler" section of the Thread Group
There is Runtime Controller where you can define for how long its children are allowed to be run.
I am load testing an e-commerce site. Under medium to heavy loads, Jmeter reports an unusually high number of errors, i.e. succes=FALSE in the resulting .csv file which translates to a fairly high % errors in the JMeter dashboard report.
On inspecting the Kibana logs, other than a few WARN, there aren't any errors and the status for all the http requests are 200. In fact, I am able to verify that the test users created in my flow are able to login and view whatever the test was supposed to do.
My question is - how is JMeter determining this error (non-200 ?) when the server side returns nothing but 200? For fewer threads, the errors are 0%.
First I would check if any assertions can fail for any reasons. So disabling any assertions and running most primitive version of the script without any possibility of failure (other than based on sampler response) would be my first step. If it doesn't help...
HTTP Sampler will fail for return code < 200, or return code >= 400, or any Java exception, which will happen when request could not be sent, or response from the server was not received (in full). Most commonly those are timeouts related to various underlying problems:
Lack of available ports on JMeter side. Since you indicated that problem happens only with more JMeter users, it is a possibility. On paper you have 65535 ports, but both Windows and Linux are limiting number of available ports to few thousands by default. Make sure you have enough ports to run the load, and monitor port usage as you ramp threads up.
Even if all ports are available, many ports may be sitting for a few minutes in TIME_WAIT or CLOSE_WAIT state, depending on how your client and server interact and other network issues. So theoretically you may have 65k ports, but practically you don't have enough. In this case it's worth checking why it happens (can point to a bug) and possibly reduce the time ports will be waiting in this *_WAIT state.
You also need to make sure you have enough RAM, JVM heap and CPU: monitor to see if there's a bottleneck that can cause such slowness that breaks the ability of a Sampler to finish its work successfully.
If all of the above is working as expected, then either server or someone between client and server (load balancer, proxy, firewall) is causing this issue.
I would start from the server, and verify that all requests you are sending are received by a server. E.g. if you send 2000 requests, and server receives 1000, which finish successfully, then from server perspective everything is fine, but Jmeter will be at 50% error rate.
Also check your JMeter log definitions and make sure failures and exceptions are written to them properly (they are multi-line messages, and may cause log definitions to break when getting to them, and thus you wont' see them). For example run HTTP Sampler that points to non-available server. See if you can diagnose what returned exception was.
Beyond that - figuring out which part is "lying" to you would be an approach, but hard to offer any more specific advice based on current information
I have test cases properly created and compiled in JMeter using the badboy. I ran the test for 1 Thread 1 ramp-up period and 1 Loop count (screenshot of the settings are attached with the query) and the test runs completely fine. Now I increased the Threads to 20 and it runs fine but when I start increasing it more like 50 or 80 threads then after few test cases the script logs out. I am testing an application based on JSF and I have taken care of the faces issue where the ViewState have to be passed to every next request being sent so the session is maintained. The problem here is that when the number of threads increases the application takes me to the login screen after a few steps.
I have also tried by un-ticking the option "Delay Thread creation until needed"
Kindly suggest a solution
JMeter Version: 3.2
Thanks and regards,
Prasad Iyer
[Thread Setting for 1 user][1] [1]: https://i.stack.imgur.com/bcVub.jpg
[Thread Setting for 80 users][2] [2]: https://i.stack.imgur.com/rJ4gA.jpg
Blind shot: add HTTP Cookie Manager to handle JSESSIONID and other cookies (in some installations you will need HTTP URL Re-writing Modifier)
If it is already there (or does not help) inspect your application under test logs, most probably you will find some errors there (you might need to increase logs verbosity)
I am trying to simulate 100 threads request with 4 different users, all the 97 requests were sent and received but the remaining 3 requests still showing as executing.
I have to manually stop the Jmeter and then only the remaining request are passed.
Why is this happening?
Your machine probably doesn't have the resources to execute the requests or Java isn't configured appropriately. Take a look at this article and this one
In case you are running jmeter in a window mode, please check for attributes provided for heap memory etc. (those should not exceed more than half of the RAM on the machine you are running upon)