Overview
This metric shows the distribution of command response times. You can configure the buckets that are used for the distribution. Distribution buckets and ranges are
configurable (for more information see Distributing Report Sets in the Foglight Experience Monitor User Guide.
Calculation
A Command Initial Response Time is calculated for every command that contains a request and a response. For each of these commands, this metric is used to increment the counter for the appropriate bucket that is used for the response times.
Categories: Application Component, Application Component by City, Application Component by Country, Application Component by ISP, Application Component by Region, Application Component by Subnet, Enterprise, HTTP Protocol, Server, Site
Type: Distribution
Command Network Latency
Overview
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.
Calculation
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:
• Tstart = time data packet is sent
• Tend = time ACK for data packet is received
• RTT= Tend – Tstart
Since round-trip times can vary throughout the life of a TCP connection, the samples for the round-tip time are averaged into a smoothed round-trip time (SRTT) estimate. Categories: Application Component, Application Component by City,
Application Component by Country, Application Component by ISP, Application Component by Region, Application Component by Subnet, City, Content Type, Country, Enterprise, Hit, HTTP Protocol, ISP, Page, Region, Server, Site, Subnet, User Agent, User Session
Type: Standard Metric
SQL: CommandNetworkLatency
Command Network Latency Current SRTT
2 ---
Command Processing Time
Overview
In order to respond to an HTTP request, Web servers (for example, Apache or Microsoft's Internet Information Server) utilizes a variety of resources such as databases, network bandwidth, system memory and CPU. The Web server must hold many of these resources until the required response is prepared and then transmitted back to the client. The fulfillment of an HTTP 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:
• parsing of the HTTP request by the Web server to determine which page is being requested and with what parameters
• directing the request to the code that supplies the page
• accessing back-end resources such as database servers or storage area networks • preparing and formatting output parameters
• generating HTML and formatting an HTTP response message.
Note Unlike the Command Completion Time metric, the Command Processing Time metric does not include network delays nor does it include client side processing delays.
Categories: Application Component, Application Component by City, Application Component by Country, Application Component by ISP, Application Component by Region, Application Component by Subnet, City, Content Type, Country, Enterprise, Hit, HTTP Protocol, ISP, Region, Server, Site, Subnet, User Agent, User Session
Type: Standard Metric
Special Considerations
Some commands include a request but not a response due to the user halting the command (with a TCP Reset) or due to the server being overloaded. For these
commands, the command processing time is undefined and is not included in the mean, minimum, maximum, or standard deviation statistics.
Calculation
Command 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 requested command. The processing time for a single command is calculated by adding together the following three types of processing:
• Initial Request Processing (measured by the Command Initial Response Time
metric)
• Data Burst Processing
• Acknowledgement Processing
Each command has only one occurrence of initial request 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.
Initial Request Processing (this is also called Command Response Time)
Data Burst Processing
Interval Start The client sends last block of data in a new request. The client sets a PUSH flag in the TCP header, indicating it has no more data to send and is waiting for the server to respond (last packet in a client request).
Interval Stop The server begins to send a response to the client request (for example, first packet server response).
Interval Start The server begins a burst of data packets. Interval Stop The server completes a burst of data packets.
Acknowledgement Processing
The command processing time for a single command is calculated by adding all of the above intervals together.
Interval Start The server is no longer transmitting data and the client sends an acknowledgement indicating it is ready for more data.
Interval Stop The next packet the server sends in response to the acknowledgement.