Understanding the results of a Web Drill Down
search cancel

Understanding the results of a Web Drill Down

book

Article ID: 254737

calendar_today

Updated On:

Products

AppNeta

Issue/Introduction

I need assistance in understanding the results of a Web Drill Down

Resolution

When viewing your Web Drill down,  you will see results such as this:

 

But how should you interpret these results?

 

This diagram is comparing resource timing and performance charts.

  • First line shows network time, server time, and additional network time.
  • Second line shows blocking, DNS lookup, connecting, waiting, and receiving.  DNS lookup, connecting, and part of waiting map to network time. 
  • Part of waiting maps to server time. 
  • Part of waiting and receiving map to the second network time.
  • Latency is responsible for the network time that maps to waiting.

    In general, the information on the Web Drill-down page can be used to determine where the most time is being spent during script execution. If you are having performance issues, identifying the elements that most negatively affect performance enables you to determine where the largest efficiencies can be gained. Keep in mind that some of these activities occur concurrently so making them more efficient may not result in significantly faster page load times.

Diagram comparing resource timing and performance charts.

 

Resource Timing chart - represents the percentage breakdown of time required to acquire the page resources for the selected part of the timeline into the following phases:

  • Blocking - the time spent in a browser queue waiting for a network connection.
  • DNS lookup - the DNS resolution time; time taken to resolve a domain name in the URL. The DNS server must "look up" the IP address associated with the domain name.
  • Connecting - the time taken to establish a TCP connection with the web server.
  • Sending - the time required to send an HTTP request to the web server.
  • Waiting - the time spent waiting for a response (the first byte of information received) from the web server.
  • Receiving - the time required to read the entire response (receive all information, first byte to last byte) from the web server.

 

Performance chart - shows the amount of script execution time associated with the network, the server, and the Monitoring Point's internal web browser. Given that many operations are typically occurring in parallel, at a given point in time, if we are waiting on the network, we count it as network time. If we are not waiting on the network but are waiting on the server, we count it as server time. If we are not waiting on the network or the server, we count it as browser time.

  • Network - the amount of script execution time associated with the network. This is comprised of two parts: the time it takes to establish a connection and send the resource request to the server, and the time between when the server transmits the first byte of the response and when the browser receives last byte of the response.
  • Server - the amount of script execution time associated with the web server. This is the time between the server receiving the request and transmitting the response (calculated as the time the first byte of the response is received by the browser minus one way network latency).
  • Browser - the amount of script execution time associated with the browser. This is the time the Monitoring Point's internal browser must wait for a network connection and the time it takes to render the page after all the content is received (though browser rendering begins after the first byte is received). It is the time not attributed to the network or server.

 

You'll find additional information here:

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/appneta/GA/analyze-results/web-application-performance-monitoring-experience/experience-charts.html