| Measurement |
Description |
Measurement
Unit |
Interpretation |
| Availability |
This measurement
indicates whether the configured URL is indeed available or not. |
Percent |
Availability
failures could be caused by several factors such as the web server
process(es) being down, the web server being misconfigured, a
network failure, etc. Temporary unavailability may also occur if
the web server is overloaded. Availability is determined based on the
response code returned by the server. A response code between 200 to
300 indicates that the server is available. |
| Response_time |
This measurement
indicates the time taken by the eG agent to get the configured web page. |
Secs
|
Response time
being high denotes a problem. Poor response times may be due to the
server being overloaded or misconfigured. If the URL accessed involves
the generation of dynamic content by the server, backend
problems (e.g., an overload at the application server or a database
failure) can also result in an increase in response time. |
| Tcp_connection_availability
|
This measure
indicates whether the test managed to establish a TCP connection to
the server. |
Percent |
Failure to
establish a TCP connection may imply that either the web server
process is not up, or that the process is not operating correctly. In
some cases of extreme overload, the failure to establish a TCP
connection may be a transient condition. As the load subsides,
the server may start functioning properly again. |
| Tcp_connect_time |
This measure
quantifies the time for establishing a TCP connection to the web
server host. |
Secs
|
Typically, the
TCP connection establishment must be very small (of the order of a few
milliseconds). Since TCP connection establishment is handled at the
OS-level, rather than by the application, an increase in this value
signifies a system-level bottleneck on the host that supports the web
server. |
| Server_response_time |
This measure
indicates the time period between when the connection was established
and when the server sent back a HTTP response header to the client. |
Secs
|
While the total
response time may depend on several factors, the server response time
is typically, a very good indicator of a server bottleneck (e.g.,
because all the available server threads or processes are in use). |
| Response_code |
The response code
returned by the server for the simulated request |
Number
|
A value between
200 and 300 indicates a good response. A 4xx value indicates a problem
with the requested content (eg., page not found). A 5xx value
indicates a server error. |
| Content_length |
The size of the
content returned by the server |
KBytes
|
Typically the
content length returned by the server for a specific URL should be the
same across time. Any change in this metric may indicate the need for
further investigation on the server side. |
| Content_validity |
This measure
validates whether the server was successful in executing the request
made to it. |
Percent
|
A value of 100%
indicates that the content returned by the test is valid. A value of
0% indicates that the content may not be valid. This capability for
content validation is especially important for multi-tier web
applications. For example, a user may not be able to login to the web
site but the server may reply back with a valid HTML page where in the
error message, say, "Invalid Login" is reported. In this
case, the availability will be 100 % (since we got a valid HTML
response). If the test is configured such that the content parameter
should exclude the string "Invalid Login," in the above
scenario content validity would have a value 0. |
| Data_xfer_time |
The time taken for the download to complete |
Secs
|
|
| Throughput |
The speed of the download |
Kbps
|
This value is calculated as a ratio of Content_length and Data_xfer_time. Ideally, this value should be high. |