Network latency is the time required for a packet, from the server, to traverse the network to the client (or vice versa). The agent analyzes network traffic utilizing characteristics of the TCP protocol stack to estimate this metric.
In a TCP connection, each packet that contains data must be acknowledged by means of another packet (ACK packet) from the receiving side. By measuring the delay from when a data packet is sent until the ACK is received, a passive monitor can calculate a round trip time:
In order to respond to an request, servers utilize a variety of resources such as databases, network bandwidth, system memory and CPU. The server must hold many of these resources until the required response is prepared and then transmitted back to the client. The fulfillment of a request therefore involves network delays and some processing time on the client side as it interprets the response it receives.
This metric measures the total time needed to build a response for the request and send the results back to the client. During that time, many of the resources required to formulate the response may be partially or fully dedicated. The following delays are included in this metric:
Some requests do not a response due to the user halting the request (with a TCP Reset) or due to the server being overloaded. For these requests, the processing time is undefined and is not included in the mean, minimum, maximum, or standard deviation statistics.
Processing time is calculated by looking at network level events that indicate the front-end server (or supporting back-end servers) are busy working on the request. The processing time is calculated by adding together the following three types of processing:
After the initial request processing, the remaining processing is either repeated data burst processing and/or repeated acknowledgement processing. The following describes how each of these types of processing are measured.
This metric indicates the average number of requests that have been sent to a server but have not received any responses, over all the requests received by that server during a period of one second. If a server becomes overloaded, the value of this metric increases as the server receives requests, but is unable to respond. By monitoring this metric, it is possible to get an early warning of an overload condition.
© 2020 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Términos de uso Privacidad