| Measurement |
Description |
Measurement Unit |
Interpretation |
| Availability |
This measurement indicates whether the server was able to respond successfully to the
query made by the test. |
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 server to respond to the requests it receives. |
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 |
KB |
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. |
| Dns_availability |
Indicates whether the DNS server was able to respond successfully to the request made to it. |
Percent |
While the value 100 for this measure indicates that the DNS server is available and successfully responded to the request, the value 0 indicates that the DNS server is unavailable or is not responding to requests. Availability failures could be caused by many reasons such as a network failure. Sometimes, the DNS server may be reachable through basic network testing, but may not respond to DNS queries from clients.
Note:
This measure will be able to report a value only if the url parameter of the test is configured with a domain name-based URL - eg., http://www.eginnovations.com, http://www.eBooks.com. If the url parameter is configured with an IP-based URL instead - eg., http://192.168.10.21:80, http://192.168.10.34:7077 - then, this measure will not report any value. This is because, to report the availability of the DNS server, the test attempts to connect to the DNS server and resolve the domain name in the URL to its IP address. If the test is able to perform domain name - IP address resolution successfully, it reports the value 100 for this measure. If the resolution fails, the test reports the value 0. In case of an IP-based URL naturally, the test will not be able to find any domain name to resolve. The test therefore will not report any value for this measure in that case. |
| data_Xfer_time |
Indicates the time taken for a data transfer between the drive and the host system. |
Secs |
Data transfer time being high denotes a problem. |
| Dns_response_time |
Indicates the amount of time taken by the DNS server to respond to a request made to it.
This measure will appear only if the Report DNS Time parameter is set to Yes. |
Seconds |
A low value is preferred for this measure.
A sudden/gradual soar in the value of this measure may indicate the deterioration in user experience. |