1. Scrub across the time range chart to zoom in on a particular time period. Click a blue pip in user experience or milestone breakdown to go to the drill-down page where you can see complete results for the script execution. An alert banner will appear on this page if the web path is targeting a webserver that does not respond to icmp, and you’ll be prompted at that time to select a supplementary target.
  2. Move along the timeline to see results from a different execution. See how the server-network-browser breakdown works in transaction performance.
  3. Each piece of a webpage—images, stylesheets, javascript, etc.—has to be requested separately. Each row in this panel shows you the name, type, and domain of a requested resource, along with a bar graph showing how the download time was spent. The bar graphs are aligned into a waterfall chart so you can see how each request corresponds to the progress of the entire page.
Blocking
Time spent in a browser queue waiting for a network connection.
DNS lookup
Time spent resolving the domain name in the url.
Connecting
Time spent establishing a tcp connection with the web server.
Waiting
Time spent waiting for the first http response from the web server.
Receiving
The time it took for the server to send the entire response starting from the first byte received.

Transaction performance

appview_latency_etc.png

The transaction performance panel shows a breakdown of the milestone time by server, network, and browser. But how does APM derive these times? Most page loads are complex interactions that involve downloading a lot of elements—images, javascript libraries, stylesheets, etc.— from multiple servers. When there are performance fluctuations, it’s important to be able to tell at a glance when and why they are occurring. APM gives you this insight by apportioning the total time taken to complete a scripted transaction or an individual milestone into three categories: server, network, and browser.

Network time
Comprised of two parts: the time it takes to establish a connection and send the resource request to the server, and the time between receiving first and last byte of the response. Modern browsers download many resources in parallel; so, while network time is calculated for each resource in the milestone and then totaled, concurrent times are counted only once.
Server time
The time between the server receiving the request and the browser receiving the first byte of the response, adjusted for network latency. As with network times, server activity may be happening in parallel for many resources, so we count concurrent times only once.
Browser time
The time it takes for the APM internal browser to render the page after all the content is received; what’s important to understand is that browser rendering begins after the first byte is received, and occurs in parallel to all of the other activities you see in the milestone performance waterfall chart.

So how do you take advantage of the network, server, browser breakdown? What you want to do is look at each time as a percentage of the total page load time. Find the biggest color block on the bar graph and speed up that element because chances are it’s the one slowing things down; when you do, you’ll see that color block get smaller and the others get bigger. If performance is still slow, repeat. This is how the transaction breakdown is useful: it keeps you focused on the elements that are most impacting performance so that you can resolve issues faster. Keep in mind that, out of context, the individual times won’t give you much information about an element’s impact on page load; arbitrarily shaving off server time might not result in noticeably faster page load; this is especially true for browser time, since it’s concurrent with other activities.