This page describes AlertSite's Performance Measurements reported in the Monitoring Summary Report
Monitoring Summary Report
The Monitoring Summary Report
is a scheduled report that provides an overview of monitoring activity for the specified reporting period.
To schedule the report:
- Click on Reports in the Control Menu
- Select All Sites from the Site/Device dropdown
- Click the Scheduled Summary report type
- Select a fixed date range (daily, weekly, monthly).
The report arrives via E-mail and may be formatted as HTML or plain text.
The report is a tabular listing of monitored devices on the left and statistics for those devices across the top. Within each monitored device are listed the locations that monitor the device, followed by a line totaling the column stats. At the end of the report is a line totaling column stats for all monitored devices.
The following table describes each column of the report:
|| AlertSite monitoring location
| # Checks
|| Number of tests performed during the reporting period
| # Available
|| Number of problem-free tests
| % Available
|| Availability, expressed as a percentage
| Response Time
|| Response time is the accumulation of the following activities:
• DNS Lookup Time
• Server Connect Time
• Time to First Byte (web sites only)
• Time to retrieve a web page or, for non-web servers, to exercise the server protocol
| Fullpage Response Time
|| Fullpage response time is the time that it takes to retrieve a web page and all of the graphic elements within that page
| # Errors
|| Number of times that we encountered a problem
| # Warnings
|| Number of warnings generated
| # Alerts
|| Number of times that we raised an alert and sent a notification
In addition to the above definitions, for ServerAgent monitoring (see ServerAgent Systems Monitor
) the following measured quantities are used:
| # OK
|| Number of times that your site passed all tests during this period
| % OK
|| #OK expressed as a percentage
| # Threshold Errors
|| Number of times that one of your server tests exceeded its threshold value
| # Check-In Errors
|| Number of times that your server failed to check-in with AlertSite
The section below explains the Definition of AlertSite's Web Page Download Performance Measurements
Web Page Download Components
In order to accurately present how we collect web page performance measurements, we must first provide a brief review of the components that are involved in loading a web page. The following represents a typical HTTP interaction for retrieving a web page:
- DNS Resolution Time (D)
- TCP Connection Time (C)
- Redirect Time (R)
- First Byte Time (F)
- HTML Content Time (H)
- Fullpage Objects (FP)
- Response Time (RT)
- Fullpage Time (FT)
Using the initials ascribed to each component, here is a graphical representation:
Below is how we define each component.
DNS Resolution Time (D)
DNS (Domain Name Services) is the Internet's system for allowing users to utilize normal English descriptions for communicating with servers that must be addressed by IP address. For example, in order to visit the web page
your browser must first convert
into an IP address using DNS.
AlertSite DNS resolution is performed against a DNS server local to the monitoring location that communicates with the Internet's DNS servers as needed.
The DNS Resolution Time
would be represented in the Figure 1
timeline as the time between 1
TCP Connection Time (C)
The connection process to the server, known as the TCP handshake, is immediately followed by the HTTP GET/POST request for a particular web page using the URL (universal resource locator).
TCP connect time can represent a useful estimate of network latency between an AlertSite monitoring location and the target server.
The TCP Connect Time
would be represented in Figure 1
as the time between 2
Redirect Time (R)
If the HTTP server responds with an HTTP 301 or 302 then the process of getting to the desired URL is reported in the Redirect time. Sometimes more than one redirection can occur. Furthermore, each redirection may require another DNS resolution, TCP connection and HTTP GET request.
So the R
in Figure 1
might be represented in greater detail as:
This process is repeated if another redirection occurs.
is represented in the Figure 1
as the time between 3
First Byte Time (F)
The First Byte Time represents the time the browser waits between the HTTP GET/POST request and receipt of the first byte of data from the Web server responding to that request.
This number typically represents the server delay or the amount of time it takes the Web server to perform any necessary processing that is part of the HTTP GET request.
In the case of redirection, the First Byte Time represents the time between when the GET request for the final URL is made and the first byte of data in response to that final request is received.
First Byte Time
is represented in Figure 1
as the time between 4
HTML Content Time (H)
Once the First Byte (packet) of HTML response has been received, the Web server continues to send the HTML that represents the layout of the Web page. Sometimes an HTML page can be many dozens or hundreds of kilobytes. The content time is directly related to the size of the HTML.
HTML Content Time
is represented in Figure 1
as the time between 5
In DéjàClick transactions, an event may load a page which contains multiple documents; each document may have its own content time. Since all of these documents are loaded in parallel by the browser, the overall content time value is calculated from the start of the first content load activity to the end of the last content load activity for all documents on the page.
Fullpage Objects (FP)
time (FP) can be inferred from reporting by subtracting Response Time
(RT) from Fullpage Time
(FT) or the components for each and every page object viewable in our Fullpage Report. This is represented in Figure 1
as the time between 6
Response Time (RT)
The Response Time column in all reports represents the time it takes from the beginning of the process until the entire HTML page is retrieved.
is represented in Figure 1
as the time between 1
Fullpage Time (FT)
as displayed in the AlertSite reports is represented in Figure 1
as the difference between 1
, thereby representing the entire time to interact with the Web server and retrieve the page and all referenced objects.
Customers who have SLA (Service Level Agreement)
requirements will benefit from SLA (MultiPOP) monitoring with Uptime ECT (Error Correlation Technology). This option provides Network Uptime
and Application Uptime
measurements in performance reports. The monitored web page or transaction is determined to be Up
if any test is successful during a measurement interval. Uptime statistics are especially useful for managing and assuring SLAs since these statistics accurately reveal if the web service was at all available.
Back to top
- Application Uptime is reduced by any correlated error, since a user would have been unable to complete their interaction
- Network Uptime is reduced only by correlated network errors with any of the following status codes:
- Status 1: TCP connect error
- Status 2: Timeout (can be network related)
- Status 6: No response from server (can be network related)
- Status 9: Ping error (site configured as pingable was not)
- Status 51: DNS lookup error