While running a performance test, one of the most important KPIs is server response time for your requests. Sometimes these response times may not be living up to your expectations. There may be lots of reasons for that. Sometimes it happens because of system side problems, and sometimes because of scripting problems. Since simulating real user behavior is always needed for performance testing, we should solve these things as soon as possible.
Solve The Problems For Your System
There can be multiple reasons behind high response time. To address and solve the issues, you can check out the listed options below:
1- Checking resource utilization details for your App and DB server could give you lots of useful information. If you see high CPU or Memory usage during your tests, this could be the root cause.
2- Your queries may be running slow. Check your system to see if queries are working as expected or not. Take a look at the logs for failed queries if necessary.
3- Check out your application logs for possible exceptions.
4- If the log level setting for your Application Server is in debug state, this could be problematic for your response times.
Make Some Changes On Your Script
Retrieving All Embedded Resources
When you make a request for a webpage, you get different HTML resources as response. Before providing a proper response, the browser gets the HTML, parses it and retrieves all the embedded resources.
To simulate this process, you can make some adjustments on your JMeter script. Let’s start with retrieving all embedded resources for your request samples.
On the Advanced tab of a specific request, enable “Retrieve All Embedded Resources” option. With this change, your request will act like a real time browser that gets an HTML resource.
But this is not always an ideal approach. If you are using CDN or some 3rd party add-ons, you may not need to measure the time for embedded resources.
Check The Logic Of Your Script
If one of the requests is dependent to the other requests, your response time for that request may be affected during the process. For example, let’s think about an e-commerce scenario: you add items to your cart and then you fetch your basket. If there are lots of items in your basket, the API call you made for fetching the basket could be executed slowly. So you can think about adding only one item to your basket or calling an API endpoint that will clear your basket between each iteration.
Response times may be higher under heavy load, and this is one of the main aspects of load testing. So you can think about reducing the load to see if high response time is happening because of heavy load. If response times are still higher with a low number of threads, you can understand that the problem is not about the load, it is about your system.
Is Loadium The Best Alternative to Other Load Testing Tools ? Absolutely Yes!