SummaryCalculating RTT, Network Delay, Server Delay, Total Transaction Delay, Network Jitter, Packet Loss, and the effect of normalization on these delays
OverviewApplication Performance Scores are a good way that the Exinda provides to monitor performance for specific applications. It provides information and a final score based on key network statistics:
- Round Trip Time Ñ the time take for a very small packet to travel across the network and return
- Network Delay Ñ the overall time taken for data to cross from a client to a server, or vice versa
- Server Delay Ñ the time taken for a server to respond to a request, not taking into account the travel time to the server
- Total Transaction Delay Ñ the time taken for data to cross the network from a client to the server and back. Calculated as (Network Delay from Client to Server + Server Delay + Network Delay from Server to Client)
- Network Jitter Ñ measures the variability of the network delay time. This is expressed as a multiple of one standard deviation.
- Packet Loss Ñ measures when one or more packets within a transmission are successfully sent, but fail to arrive at the destination
The normalization is done to a 1KB packet size. In some cases where protocols or applications used small packets, this normalization would return delays and statistics that were magnitudes higher than a 'standard' delays for a packet belonging to this application. This includes Citrix, RDP and other 'interactive' applications used for terminal services of various kinds. As a result, a non-normalized view was added for these applications to show the 'true' value. These most notably reply to the Network Delay and the Server Delay. On the APS page (Configuration > Objects > Service Levels) they are denoted as 'normalized' where applicable.
The APS calculation is done by the following formula:
APS = 10 * ((1 x number of satisfied samples) + (0.5 x number of tolerated samples) + (0 x number of frustrated samples)) / total samples
- A satisfied sample is performing below the baseline threshold established when it was set up
- A tolerated sample is performing between 1 to 4 times as quick as the baseline threshold
- A frustrated sample is performing more than 4 times slower than the baseline threshold
The various metrics are calculated as follows, though they are explored in more depth in the guide for APS.
Round Trip Time
Round trip time (RTT) is the measure of how long it takes for a very small packet to travel across the network and for an acknowledgement of that packet to be received. Because the Exinda is in the middle of the path between the client and the server, it sums the round trip time between itself and the server (server RTT), and itself and the client (client RTT) in order to get the full RTT. As more packets are sent from the client through the Exinda appliance to the server and back, the RTT estimate is updated by averaging new information - averages are taken for the server RTT, and the client RTT, and then the average total RTT is the summation of the two.
Network & Server Delay in a Read Transaction
When a client computer requests information from the server, the request and response are tracked to determine how long it takes for the client to send the request, and the server to send the requested data back to the client. The network delay consists of Client RTT + transaction delay through the Exinda from client -> server + transaction delay through Exinda from server -> client + Server RTT.
The server delay consists of the time between the final packet of request going through Exinda to the Exinda receiving the first response from the server, minus the Server RTT.
Total Time for Read Transaction simplifies down to (Client RTT + Exinda Transaction Delay 1 + Exinda Traction Delay 2 + the delay between request and response from Exinda to server)
Network & Server Delay in a Write Transaction
When a client computer sends information to be written to the server, the request and response are tracked to determine how long it takes for the client to send the data to the server, and the server to send acknowledgment of receiving the data back to the client. The actual calculation is much the same as in a read transaction, though the time for processing the first and final packets will be different.
To create accurate comparisons of the network delay experienced by a transaction, the appliance must analyze packets of the same size (normalized), as some transactions will involve significantly large packets, and others incredibly small ones. All other factors being equal, the transaction delays should increase with the amount of data transferred or the transaction size. To make the APS score independent of transaction size, the transaction delay metrics are normalized using a constant of 1024 bytes. The normalized network delay is calculated as follows:
Normalized Network Delay = Total Network delay * 1024 / transaction bytes
Packet loss occurs when one or more packets within a transmission are successfully sent, but fail to arrive at the destination. Packet loss can be caused by a variety of factors including network congestion, faulty network components such as hardware or drivers, or corrupted packets within the transmission. To recover from packet loss, data must be retransmitted to the destination to complete requests successfully. The amount of data retransmitted per flow is used to calculate the Network Efficiency metric.
Efficiency = 100% * (transferred - retransmitted) / transferred
Network Loss = 100 - Efficiency
For more detailed information, see this document regarding how to set up APS on the Exinda.