Investigating a poor application performance score (APS)
From an application performance chart, click Show details. A new screen charts the measures contributing to the APSApplication Perfromance Score:
- Network delay and normalized network delay – the amount of time for data to traverse the network (on the wire)
- Server delay and normalized server delay – the amount of time for a server to respond to a request
- Round trip time – the amount of time for data to travel from a device across a network and return
- Jitter – a measure of the variability of Network Delay. We define it as one standard deviation of the Network Delay.
- Inbound loss and outbound loss – the amount of data retransmitted
Inspect the charts to determine which attribute caused the poor APS score. For example, if the server delay measures are good but the network delay measures are bad, then you know that the network is to blame and perhaps you can do something about it. If the network delay measures are good but the server delay measures are bad, then you should have someone investigate why the server is performing poorly.
Note that if the baselining period was not typical, then the calculated thresholds may be overly high or low. For example, if the application was baselined on a weekend when there was very little traffic, then the thresholds may be much lower than would be expected when the network is in a typical use scenario. Similarly, if the application was base-lined during an extremely busy time, such as when most employees are watching an online CEO webcast, then the thresholds may be much higher than would be expected when the network is in a typical use scenario.