This help topic provides in-depth explanations of Transaction Perspective and Application Perspective components.
Network Components are accurate measurements of the interactions between the browser and its underlying network communications software, called WinInet (the Windows Internet Applications Program Interface). It is WinInet that connects the browser to the Internet through the TCP/IP protocol suite. (WinSock, the Windows Socket Applications Program Interface, is an alternative interface that is similar to that used by UNIX systems. It is not used by the Internet Explorer browser, although it can be used by plug-ins and Java running within the browser. The WinSock interface is sometimes used by WinInet to perform its tasks.) Extensive testing at Keynote with custom-built tools has been used to validate the timings at the WinInet interface and compare them with any concurrent WinSock activity.
Both types of components are described in detail below. (The names of corresponding Data Feed fields are shown in parentheses after the component names.)
User experience components
These components are reported by Transaction Perspective only because they rely on the Internet Explorer browser.
Time to opening page (Time_to_Opening_Page)
Summary: This measures the user’s perception of the time needed to start opening the page. Timing begins with the first action performed after the agent has decided to move to the next page. Timing ends when the first “Opening Page” message would be displayed in Internet Explorer’s status bar.
Detail: The agent tells its embedded Internet Explorer to begin moving to the next page, Internet Explorer issues the “Before Navigate” event, and timing starts. Timing stops when Internet Explorer issues a StatusTextChange event message containing the string “Opening Page.”
This is a measurement of the user experience time until the “Opening Page” message is sent by Internet Explorer; it is not a measurement of network protocol behavior detail. This time may include DNS lookup time, initial connection time, SSL time, redirection time, request time, and a portion of the page download time prior to the Internet Explorer browser’s producing the “Opening Page” signal. There are rare cases in which Internet Explorer issues the “Opening Page” message before any or all of these actions.
Page download (Page_Download_Time)
Summary: This measures the time between when the Internet Explorer browser produces the “Opening Page” signal and when the Internet Explorer browser would display the last “Done” message in its status bar.
There are also cases in which Internet Explorer displays a “Done” message in its status bar before the time when the page has finished downloading. (A typical example involves a database search result that is displayed slowly.)
Detail: Timing begins when the User Experience Component Time to Opening Page stops. Timing stops when Internet Explorer announces that the HTML requests have been fulfilled in the last expected page of the transaction step.
The time between transaction steps (i.e., between the end of one page’s timer and the start of the next page’s Time to Opening Page) is not shown in MyKeynote. The time between steps can be deduced from the Data Feed data, which shows the start time for each page in the transaction. However, that time between steps also includes some agent processing time, which is always more than three seconds to ensure that the DOM is completely built and analyzed before navigation to the next page starts.
Finally, there are cases in which the number of pages in a transaction step is not the same as when the transaction was recorded. The agent always tries to complete the number of pages indicated in the recorded transaction script. If the actual number of pages is smaller than when the script was recorded, the agent will stall and the transaction step will time out. If it’s larger, the additional pages will be ignored.
Estimated cache time
**Summary: ** This component is calculated by estimating what the network performance of the transaction WOULD be if the objects that can be cached were cached. This calculation is performed on the agent and it is reported for all transactions.
Detail: There are two basic scenarios for playing a transaction as regards browser caching:
- First-Time-Run – The Browser Cache is empty, no objects are being cached.
- **Cached-Run ** - The Browser Cache contains objects that are previously (outside of the current transaction) downloaded and cached. Not all downloaded objects are cached. The caching policy of specified by the Web site design, through its HTTP headers.
For consistency across products the “cacheability” of an item is simulated by the measurement agents. The simulated cache has been modeled after the caching notes in the HTTP/1.1 RFC (RFC 2616) rather than on the cache of a particular browser. RFC 2616 specifies that an item is generally considered cacheable unless one or more of the following criteria are met:
- The item has a cache-control header with “no-cache,” or “no-store” properties.
- The item has a cache-control header with a max-age set to zero or less seconds.
- The item has a pragma header with “no-cache,” or “no-store” properties.
- The item has an expires header without a date header or with a data header that has an invalid date format.
- The item has an expires header with an invalid date format.
- The item contains an expires header that according to the date header is in the past.
If none of the above criteria are met, the item is automatically considered to have passed a freshness check to the server. Thus all items not meeting one of more of the above conditions will be considered “cached.” when estimating cached time.
Note that due to the way our simulated cache works it cannot issue freshness checks to the Web site it is measuring. Therefore, the simulated cache must assume that all freshness checks pass. Pages that would be considered “uncacheable” due to a failed freshness check are instead considered cacheable by our simulated cache. This can lead to slightly more optimistic caching results for some web sites than the RFC would normally allow.
DNS lookup (DNS_Time)
**Summary: ** This is the time to translate the host name (for example, www.keynote.com) into the IP address (for example, 188.8.131.52). The agent performs this translation by using the Internet’s standard Domain Name Service (DNS). Transaction Perspective measures Internet Explorer’s internal operation precisely, including the fact that the results of DNS lookups can be temporarily cached. Therefore, each hostname is usually looked up only once per transaction.
Detail: Timing of DNS Lookup starts when WinInet announces that it is beginning to translate a hostname into an IP address; timing ends when that translation is complete.
The DNS lookup request may make Windows send a query into the Internet’s DNS system, or, if the hostname has been previously retrieved in this transaction, it may simply fetch data from the Windows internal cache. The Internet Explorer DNS cache is flushed between transactions.
Initial connection (Initial_Connection)
**Summary: ** This measures the network connection round-trip time between the browser and the server. It is an excellent measure of pure network round-trip latency. Note that many web sites use HTTP/1.1 and persistent connections; that allows a connection to be re-used by multiple page elements. Initial Connection time for re-used connections is zero.
**Detail: ** Windows establishes a connection with a server by sending a very short TCP “SYN” packet and receiving a very short TCP “SYN ACK” packet in return. (It then sends a third packet, “ACK,” to the server to complete the connection’s establishment.) The Initial Connection timer starts when Windows is asked to send the “SYN” packet, and it stops when Windows announces that the connection is open because it has received a “SYN ACK” packet (and therefore has sent the third, “ACK” packet).
This is an excellent measure of pure network round-trip time, because the packets are short and connection establishment overhead is very low at both browser and server. The only software involved is low-level, efficient TCP code at both ends; the applications (browser, web server) are not involved in connection establishment.
Summary: After a TCP Connection is made, a Secure Socket Layer (SSL) session can be established on top of it, if required. (For example, an SSL session is used for downloading a secure page with HTTPS.) SSL is the time needed to perform the protocol handshakes that establish an SSL session between the browser and the server. It does not include any extra time needed to perform the encryption/decryption during data transfer; that time is included in the data transfer timings.
An SSL session can be re-used by all TCP connections going to the same server. The SSL time is zero for a re-used SSL session.
Detail: SSL is derived by calculating the time between the end of the Initial Connection and the beginning of Redirection (or Request, if Redirection isn’t being done by the Web site). It is not a direct measurement of the SSL handshake packets. SSL is measured only if WinInet signals that a secure connection has been established. Otherwise, any time between the end of the Initial Connection and the beginning of Redirection (or Request, if Redirection isn’t being done by the Web site) is included in Client Time, as discussed below.
The establishment of the SSL session is usually time-consuming, but the overhead of performing the encryption/decryption during data transfer is usually very low. Therefore, the performance impact of SSL usually appears in the session-establishment (SSL) phase, not in the data transfer (for example, Base Page Download or Content Download) phases. Connections over dial-up are an exception to this rule, because encrypted data cannot be compressed by a dial-up modem’s compression hardware. That often results in a considerable performance penalty during data transfer, especially for data that would otherwise be easily compressible (for example, HTML text).
Summary: If the Web server’s HTTP response tells the browser to go to another location, the elapsed time needed for that redirection or series of redirections is measured by the Redirection timer. The Redirection summary timer starts after the initial connection is made to the first Web server, and it stops after the connection is completely established to the final Web server in the chain of redirections. Detailed information that shows each redirection separately for each individual measurement is available in MyKeynote and in Data Feed. Redirection information is normally stored only for the base page; redirection information for frames and other content is stored only if a content error occurred for the page.
Detail: Redirection may be caused by different methods. The three major methods are:
- The response to an HTTP request can tell the browser to go elsewhere (for example, a “302 Redirect”);
- The Web page’s HTML can contain a Refresh command that tells the browser to go elsewhere after a pause of zero or more seconds (for example, <META HTTP?EQUIV=”refresh” CONTENT=”0; URL=http://www.keynote.com/”> ); and
The first redirection method is called a “server-side” redirection, as it’s controlled by the server; the other two methods are called “client-side” redirections, as they’re controlled by code running in the browser.
Because the agent is built using Internet Explorer, it simply watches Internet Explorer perform the redirections. Most of these redirections (using the second and third methods above, and using other minor methods) are considered to be a part of the page’s content, and they therefore appear in the Content Download time, although any timing pauses involved in such redirections are not included. (For example, a redirection may take place after more than zero seconds. If so, the timing countdown itself is not included in any of the network-level component measurements, although it is included in the user experience component measurements.) If a content error occurs during the download, then the MyKeynote and Data Feed data includes detail records showing the details of the redirections. (For example, there will be additional HTML files.) Redirections inside frames or during content fetches are also considered a part of the page’s content and are handled as part of the Content Download time, with details being stored only if there is a content download error. The Keynote transaction script stores the number of these redirections that were seen during script recording, and it assumes that the transaction step has ended when the last expected page completes downloading. (See the description of Page Download time, above, for further discussions.)
However, redirection because of HTTP redirection reply (that is, a “3xx-series” HTTP reply), the first method described above, is handled by the Redirection timer. In that case, the agent starts the Redirection timer after the first SSL timing is complete. (If there isn’t any SSL, it starts the timer after the first Initial Connection is complete.) The Redirection timer stops when the SSL (or Initial Connection, if there isn’t any SSL) is completed to the final Web server.
The component details inside the redirections are recorded and can be obtained by double-clicking the redirection graphic in MyKeynote or by looking at the redirection detail records in a Data Feed download.
The behavior of the Redirection summary timer is shown in the figure below. The upper three rows show the progress of the Web page retrieval as it moves from the first Web server (top line) to the second web server, and finally to the last Web server - which then supplies the complete page content. The bottom row shows the timers that are stored by Keynote for access by MyKeynote or Data Feed summaries. (Remember, the details are available by double-clicking in MyKeynote or by examining the detail records in Data Feed.) As you can see from the figure, the DNS, Initial Connection, and SSL Handshake times are from the first connection, before the redirections. The Request, First Byte Download (Time_to_First_Byte) and subsequent measurements are from the final page.
Notes: The Keynote agent does not have a fixed number of redirections that it will follow; it simply continues producing redirection detail records as long as Internet Explorer is following redirections.
To force measurement of redirections within frames or redirections of content fetches at all times, and not just when errors occur, you should measure the frame or piece of content as if it were an entire page.
Request time (Request_Time)
**Summary: ** The Request Time is the amount of time needed by Internet Explorer to send the request into the Internet. For short file requests (for example, a GET), this should be very fast. For longer requests (for example, a long POST), this will be a noticeable time.
Detail: The Request Time timer starts when Windows notifies Internet Explorer that it has started sending the request. It stops when Windows sends a notification that the request has been sent.
This timer depends on notifications sent by Windows to Internet Explorer. Windows announces that it has sent the request when it sends the last packet into the local TCP/IP stack’s WinInet interface; it does not wait until the last packet has been acknowledged by the destination Web server.
First byte download (Time_to_First_Byte)
Summary: The elapsed time between the end of the Request and the time that Internet Explorer finishes receiving the first data block of the response from the Web server.
Detail: The First Byte Download timer starts when the Request timer stops; it stops when the first data block from the remote Web server has been completely transferred to Internet Explorer.
“First Byte Download,” “Time to First Byte,” and “Time to First Packet” are terms that are used interchangeably in Keynote documentation. In all cases, the timer is stopped when the first data block finishes arriving inside Internet Explorer from the WinInet interface. Note that this data block is usually the same size as the Internet packet, but that cannot be guaranteed.
Base page download (Base_Page_or_Content_Download in base page Data Feed record or in page summary Data Feed record)
Summary: The Base Page Download timer measures the elapsed time needed to receive the first file from the Web server after the first block of that file has been received.
Detail: The Base Page Download timer starts when the first block of the Web page’s first file finishes arriving from the Web server (which is when the First Byte Download timer stops); it stops when Internet Explorer completely receives the last data block of that file from Windows.
Frame downloads, .css downloads, etc. are separate files from the base page file, and they may therefore continue past the end of the Base Page Download. They are considered to be content files.
The same Data Feed data field identifier, Base_Page_or_Content_Download, is used for both the Base Page Download timer and the Content Download timer. The data fields appear in different Data Feed record types, however. The Base Page Download timer is reported by the Base_Page_or_Content_Download data field in the Base Page Data Feed Record and in the Page Summary Data Feed Record; the Content Download timer is reported by the Base_Page_or_Content_Download data field in the Content Detail Data Feed Record.
Content download (Base_Page_or_Content_Download in content detail Data Feed record)
**Summary: ** Content Download has similar, but different meanings when used within an individual element timing and when used in the page summary.
- For page elements, Content Download is the same as the Base Page Download timer, except it is for every element except the base. It starts when the first block of the element file finishes arriving from the Web server (which is when the First Byte Download timer stops); it stops when Internet Explorer completely receives the last data block of that file from Windows.
**Detail: ** For the page summary, Content Download is calculated by subtracting the timestamp of the time when the last block of the last page element arrived from the timestamp of when the last block of the first file (the base) arrived.
The same Data Feed data field identifier, Base_Page_or_Content_Download, is used for both the Base Page Download timer and the Content Download timer.
Client time (Client_Time)
**Summary: ** Client Time is the total time in a page element download during which data transfers or other network activity were not occurring. Although shown at the end of the displayed download time bar chart in MyKeynote, it may be the sum of many different timings within the download of that individual element - not just at the end. For example, the pause between DNS Lookup and Initial Connection while WinInet prepares to open the connection is a part of Client Time.
The Client Time in the MyKeynote summary record and the Data Feed summary record is identical to the Client Time for the base file.
**Detail: ** The total time needed to download an element is the time between when DNS Lookup begins and the time when Internet Explorer has completely received the last data block of the element’s file. Client Time is obtained by subtracting all of the various network component timers from that total time.
Client Time is usually extremely small; noticeable Client Time may occur if Windows pauses momentarily to execute another process while downloading the file. This may be caused by the Internet Explorer browser rendering an image or by many other factors, such as a Windows background process or a Keynote systems maintenance process. Note that the Keynote agent runs only one transaction at a time; therefore, these pauses are not caused by unrelated transactions.
A refresh delay (for example, <META HTTP-EQUIV=”refresh” CONTENT=”15; URL=http://www.keynote.com/“> or any equivalent timer delay in downloaded scripts or code does not increase Client Time and does not increase the length of the element’s total download time; those delays occur after the HTML is downloaded. Similarly, execution of java or plug-ins does not result in Client Time and does not increase the length of the element’s total download time if it uses WinSock. (If it uses WinInet and makes the WinInet calls before the page has completely downloaded from the network, then the Keynote agent will detect and track those WinInet calls and timings.)
Total measurement time (Measurement_Network)
Summary: This is the total time needed to download a Web page from the network’s point of view. It starts from the beginning of the base file’s DNS lookup, and it ends when the last packet of the last page element has been delivered by WinInet to Internet Explorer for processing. It does not include any times during which no page element activity is taking place.
Detail: Total Measurement Time is calculated by taking the time when the last packet of the last page element has been delivered by WinInet to Internet Explorer for processing and subtracting the time when the base file’s DNS lookup was started. This time is then further decreased by subtracting all time periods during which there is no page element activity (i.e., there is a blank vertical column on the MyKeynote detail graph of the page). For example, refresh delays (for example, <META HTTP-EQUIV=”refresh” CONTENT=”15; URL=http://www.keynote.com/”> do not increase the Total Measurement Time.
To obtain the total time as seen by the user, including any refresh delays and other delays during which Internet Explorer is doing internal processing and not doing any page element activity, add together the User Experience components Time to Opening Page and Page Download. Client Time is considered to be time “during which page element activity is taking place”; it is not excluded from Total Measurement Time.
Total bytes downloaded (Content_Byte)
Summary: This is a count of the total number of bytes, including HTTP bytes but not including TCP headers, that were downloaded from the Web server.