CODEWITHSUNDEEP
jmeter
la1
la1

Reputation: 539

There is Jmeter response time difference between Jmeter run results and manually captured the response time

There is Jmeter response time difference between Jmeter run results and manually captured the response time from the local system using stop watch on the web application.

  1. Browse the web app from local windows system and use stop watch to see the response time to load the page.
  2. Run the Jmeter in non-gui/gui mode and observe the response time (used Listeners only to debug, when run the script no listener was added)
  3. Can see there is a difference in both. Please suggest how to know if Jmeter has captured the correct response time.

Upvotes: 0

Views: 3810

Answers (2)

Dmitri T
Dmitri T

Reputation: 168072

Given you properly configure JMeter you should get the same or similar response time for the same request. "Proper" configuration stands for:

  1. You should configure JMeter to retrieve embedded resources and use parallel thread pool of ~5 threads for this

    JMeter embedded resources

    This options "tells" JMeter to fetch images, styles and scripts referenced in the main HTML page and do it in parallel like real browsers do

  2. Add HTTP Cache Manager to your Test Plan. Real browsers download embedded resources but do it only once, on subsequent requests the resources are being returned from disk cache, no actual request is being made. HTTP Cache Manager enables cache simulation and cache-control headers handling.
  3. Add HTTP Cookie Manager to represent cookies/sessions and deal with cookie-based authentication
  4. Add HTTP Header Manager to your test plan to represent browser headers. It might be important as i.e. missing Accept-Encoding header may disable server-side compression therefore client will receive much more data and it will take more time.

  5. Assuming "good" JMeter configuration you should see more or less same behavior

    JMeter Response Time versus Real Browser

    If there are still differences - capture the requests sent by JMeter and the browser using a sniffer tool like Wireshark and amend JMeter configuration to eliminate the differences

Upvotes: 3

Yuri G
Yuri G

Reputation: 1213

JMeter have three basic measurements it captures per request:

  • Elapsed Time (which is overall timespan from the point when it just starts sending request to the last bit received)

  • Latency (which starts the same point in time and ends when server starts responding)

  • And Connect time (which is included in latency and is basically the time for handshakes with server, including SSL/TLS negotiations)

So if you set a data writer among your listeners (e.g SimpleDataWriter, although AggregateReport & SummaryReport can do it as well), you'll see these metrics in your data file (while standard listeners/visualisers/aggregators stuck to elapsed time only).

But mind that these metrics doesn't include response rendering, and especially any code to be executed by browser.

JMeter just doesn't do it at all: obviously, it measures just the combined performance of Server + Network, skipping everything on the client side (except for bare necessities, like protocol negotiations).

That might explain the difference you've experienced.

As well as the difference between logged server processing times & the response times measured by JMeter: server just doesn't count what the network brings in.

PS And you don't have to sit and click on stopwatch with your browser: modern ones have a Dev Tools capable of showing you the precision timings divided by stages. E.g., just call Ctrl+Shift+I in Chrome, switch to network tab & behold the timings right there as you doing your requests.

Upvotes: 2

Related Questions