Differentiating Response Times in JMeter with Embedded Resources
To make JMeter behave more like a browser that gets HTML, enable the “retrieve all embedded resources” option.
In your Thread Group Right Click -> Sampler -> HTTP Request -> Advanced -> Retrieve All Embedded Resources
But this might be a problem when measuring response time. It’s important to understand that the response time that JMeter shows for each HTTP request with the embedded resources enabled will include all requests, both the primary and the secondary ones that are triggered (embedded).
You don’t necessarily want to measure the embedded resources response times, for example if you are using a CDN or 3rd parties or you are interested in a certain endpoint.
So, how do we distinguish the response times corresponding to the main request and the embedded requests?
The solution is very simple, we just have to use the "View Results in Table" component. This listener shows individual response times of the requests, provided that we enable the option "Child samples" (see the image below).
This table in the screenshot below shows the response times not only for the main request to “opencart.abstracta.us”, but also for all its embedded resources. We can see the response times in the column “Sample Time” in milliseconds. The first row corresponds to the main request and the last one corresponds to a Transaction Controller containing the HTTP Request sampler.
Through this listener, we can see the response time for the main request, separately from the response time for each embedded resource.
But a new problem arises here. Have you noticed that the sum of the response times is larger than the response time registered by the Transaction Controller? Shouldn’t they be the same? What is the reason for the difference?
The answer is that the secondary requests are made in parallel threads. When we select the option “retrieve all embedded resources” there is another option next to that checkbox, which allows us to set the number of “parallel downloads”, meaning the number of threads requesting the embedded resources.
As they are not sequential, the total response time is not equal to the sum of all the individual requests. This is an advantage for the user experience since the loading time for the web page is going to be shorter, as explained here. This is the main reason for simulating this aspect properly, but on the other hand we shouldn’t forget that using this implies that JMeter is going to use more resources for the simulation (because it needs more threads, sockets, memory, and so on).
That’s it! You now know how to differentiate Response Times in JMeter when embedded resources are retrieved.
To try BlazeMeter, put your URL in the box at the top of this page or upload your jmx file, and your test will start in minutes.