Assuming that the network's role is to effectively transfer data to the end user, the percentage of total traffic that is transferred effectively is the network performance. Low network performance does not always mean low end-user experience; some applications are less dependent than others on network conditions.

The measured total traffic includes both directions of data transfer: to and from the client, or downstream and upstream, including bytes transferred internally within the site.

Criteria for effectiveness of data transfer can be customized with regard to the used Key Performance Indicators (KPIs) and thresholds.

Key Performance Indicators (KPIs)

  • Retransmissions (Loss Rate) in both directions

  • Latency (Round Trip Time) in both directions measured for:

    • TCP handshakes only (the End-to-end RTT metric)

    • Any ACK packet (the Client ACK RTT metric)

      This is disabled by default. In some situations, however, end-to-end RTT may prove insufficient and you may need to add ACK RTT as a performance criterion. This may be due to long session duration, when the frequency of RTT measurements is rather low.

  • Effective Throughput (Realized Bandwidth)

    This is disabled by default.


  • Normals per site. In this case, you can set the KPI cut-off thresholds (the maximum values for which the metric is treated as good).

  • Constants, which are fixed customizable thresholds for simpler calculations.

For more information, see Configuring Thresholds for Network Performance Calculations.

Measurement logic

In every reporting interval, the configured KPIs are evaluated against their thresholds (see Figure 1. Comparing KPI Values with the Configured Threshold). For CAS, these thresholds are equal to the network site's average values of RTT and loss rate for all of the business days within the past 10 elapsed calendar days, increased by a predefined factor. By default, this factor is equal to 100%, such that if the values of loss rate or RTT exceed twice the average values, bytes transferred during that time are considered to be transferred while network-related problems were present.

Figure 1. Comparing KPI Values with the Configured Threshold
Comparing KPI values with the configured threshold Figure 2. Calculating Network Performance
Calculating network performance

The analysis of network performance is done on the lowest level: a single user using a single service.

Each portion of data transferred between the user and a service is flagged as affected or not affected, depending on the KPI values. The percentage of unaffected traffic is reported as network performance (see Figure 2. Calculating Network Performance). In this example, network performance = 4/5*100% = 80%.


The average values of RTT and loss rate that are used in network performance measurements are by default calculated only for recognized software services, so “not monitored” or “unknown” traffic is not taken into account. If you want the calculation to be based on all the traffic, you can change the default configuration of the AMD.

Analyzing network performance problems

Understanding the metric logic is not required to find areas for performance improvement. Follow these rules to analyze network-related problems:

  1. Problems are more obvious in high time resolution.

  2. Problems are more obvious on lower levels (at the site level rather than at the network level, and at the client level rather than at the site level).

  3. Find the underperforming sites first.

  4. After you find the underperforming sites, determine whether all or only some users are having problems.

  5. Display metric charts and analyze KPI values and transferred traffic during periods of low network performance.

To learn about site performance, see Sites Report. To learn about verifying user-related problems, see All Users Report.

  • No labels