Real user performance

Aborts

The number of operations aborted by the client. It applies to all TCP-based protocols. For example, for HTTP/HTTPS, it is the number of operations manually stopped by the user by either clicking on the Stop or Refresh buttons or selecting another URL. Note that, in the case of HTTP, this number includes Short aborts and Long aborts.

Affected users (availability)

The number of unique users that were affected by the availability problems.

Affected users (network)

The number of unique users that experienced network performance problems.

Affected users (performance)

The number of users that experienced application performance problems. For transactional protocols, a problem is noted if at least one operation is completed in time longer than the performance threshold. For transactionless TCP-based protocols, a problem is noted if user wait per kB of data is longer than the threshold value.

Application Delivery Channel Delay

In WAN optimized scenario, Application Delivery Channel Delay (ADCD) is a quality metric represented in milliseconds. The ADCD is determined by initial observation of the traffic between a client and a server. ADCD is a derivative of RTT measured on a WAN link expressed in time and as such it can be understood as latency, where the larger ADCD would indicate a higher network latency. ADCD also includes time spent in the data center WOC for traffic buffering and processing. A change of ADCD from its initial value reflects a change of quality in WAN optimization service. For example, sudden increase of ADCD would suggest that the quality of the service has worsened and conversely, a sudden decrease of ADCD value could suggest an improvement in WAN optimization.

Application performance

For transactional protocols, this is the percentage of software service operations completed in a time shorter than the performance threshold. For SMTP and transactionless TCP-based protocols, this is the percentage of monitoring intervals in which user wait time per kB of data was shorter than the threshold value.

Attempts

The number of monitoring intervals during which attempts were made to connect to a server. Note that this is counted separately for each server, client and software service. Thus, if in a given monitoring interval there are attempts to connect to three different servers, the Attempts metric will be incremented by three for that one monitoring interval. The actual value shown on the report is the sum total of all the attempts, for all the monitoring intervals, in the period covered by the report.

Availability (TCP)

Availability limited to the network context, calculated using the following formula:

Availability (application) = 100% * (All Attempts – Failures (TCP) / All Attempts

where

All attempts = all failures + all successful operations + all standalone hits not classified as a failure + all aborts not classified as a failure.

Availability (application)

Availability limited to the application context, calculated using the following formula:

Availability (application) = 100% * (All Attempts – Failures (Application) / All Attempts

where

All attempts = all failures + all successful operations + all standalone hits not classified as a failure + all aborts not classified as a failure.

Availability (total)

The percentage of successful attempts, calculated using the following formula:

Availability (total) = 100% * (All Attempts – All failures) / All Attempts

where

All attempts = all failures + all successful operations + all standalone hits not classified as a failure + all aborts not classified as a failure

All failures = all failures (transport) + all failures (TCP) + all failures (application).

Availability (transport)

Availability limited to the transport context, calculated using the following formula:

Availability (application) = 100% * (All Attempts – Failures (Transport) / All Attempts

where

All attempts = all failures + all successful operations + all standalone hits not classified as a failure + all aborts not classified as a failure.

Bad MOS calls

The number of VoIP calls with the Mean Opinion Score (MOS) rating below acceptable threshold.

Bad R-factor calls

The number of VoIP calls with R-factor value below the acceptable value.

Bad delay calls

The number of VoIP calls with delay above the acceptable level.

Bad jitter calls

The number of VoIP calls with jitter exceeding the acceptable level.

Bad lost packets calls

The number of VoIP calls with loss rate above the acceptable level.

Call duration

The average call duration.

Calls

The total number of VoIP calls. Note that for a selected software service the number of calls as seen from the sites' perspective may differ from the number seen from the endpoints' perspective. This is because in one site we may have two users taking part in the same call.

Client ACK RTT

Client ACK RTT is the time it takes for an ACK packet with no payload to travel from the user to the AMD and back again.

Client ACK RTT measurements

This metric keeps track of how many Client ACK RTT measurements were made. ACK measurement is performed during ACK packet transmission either from server or client side of the transaction.

Client RTT

Client RTT is the time it takes for a SYN packet (sent by a server) to travel from the AMD to the client and back again, as shown in the following picture.

graphical illustration
graphical illustration

A client RTT measurement begins when the SYN ACK packet from the server to the client passes by the AMD (T5). The packet reaches the client machine (T6) and is processed, while an acknowledgment is sent back to the server (T7). Client processing time impact (T7-T6) is again very low. Client RTT measurement ends when the ACK packet reaches the AMD (T8). Therefore, the Client Round Trip Time is calculated as T8-T5. Depending on the actual setup, Client RTT measurements may vary dramatically. In corporate environments, it may be a few milliseconds for LAN-connected clients or a couple dozens milliseconds for WAN-connected clients. In this case, where the client is coming from the Internet, the end-to-end Client RTT measurement is a compound of transit time through the Internet backbone as well as through the "last mile" access network. The impact of the last mile can be easily calculated, based on the connection speed and the packet size (56B in case of TCP SYN packet). For a 28 kbps dial-up connection, this amounts to 16 milliseconds one way, or 32 milliseconds for a complete round-trip measurement. For a 1.6 Mbps DSL line, this makes 56 microseconds towards complete client RTT measurement.

Client TCP data packets

The total number of TCP packets sent by the clients, excluding the traffic control packets.

Client TCP data packets lost

The number of lost TCP data packets sent by the clients, excluding the traffic control packets. The number of lost TCP packets always regards the context of the counter, for example, an application, a server or any other entity.

Client bytes

The number of bytes sent by the clients. Note that this includes headers.

Client not responding errors

The number of errors of category Client not responding .

Errors of this category occur when the server closes the TCP session with a RESET packet after the client has been idle for too long. Such a situation happens when the server TCP/IP stack detects that network connection to the client exists, but the client remains idle and does not respond. In such a case, the server closes the TCP session with a RESET packet. This may occur when the client has been silently disconnected from the network, for example, due to link failure, or the client has crashed. Note that this error will not occur if the client session has ended gracefully, that is, by closing the client application.

Client operation size

The size of a client operation. Note: an operation can be split over several packets. For traffic parsed with HTTP and SSL decrypted analyzers, Client operation size is the size in bytes of the operation request (HTTP GET or POST).

Client operations

The number of operations (for HTTP/SSL this is equivalent to the number of pages, for DB/2 it is equivalent to the number of queries) from the client side. For traffic analyzed with the analyzers General-volume and ICA (Citrix), this is the number of client data transfers for which network realized bandwidth was measured.

Client packets

The number of packets sent by the clients.

Client packets lost (client to AMD)

The number of packets sent by a client that were lost - between the client and the AMD - and needed to be retransmitted.

Client realized bandwidth

Client realized bandwidth refers to the actual transfer rate of client data when the transfer attempt occurred, and takes into account factors such as loss rate (retransmissions). Thus, it is the size of an actual transfer divided by the transfer time.

Client retransmission timeouts

Number of times retransmission timeout occurred on client connection. Calculated only for AppFlow records collected by AMD from NetScaler.

Closed TCP connections

The total number of successful or failed TCP connections.

Connection establishment timeout errors

The number of TCP errors of category Connection establishment timeout errors . This category of errors applies when there was no response from the server to the SYN packets transmitted by the client.

Connection refused errors

The number of TCP errors of category Connection refused errors, also referred to as Session establishment errors . This category of errors applies when a server rejects a request from a client to open a TCP session. Such a situation usually happens when the server runs out of resources, either due to operating system kernel configuration or lack of memory.

Custom metric (1)(avg)

The average value of user-defined metrics in category 1 observed in the HTTP or XML traffic.

Custom metric (1)(cnt)

The number of occurrences of user-defined metrics in category 1 observed in the HTTP or XML traffic.

Custom metric (1)(sum)

The sum of all values of user-defined metrics in category 1 observed in the HTTP or XML traffic.

Custom metric (2)(avg)

The average value of user-defined metrics in category 2 observed in the HTTP or XML traffic.

Custom metric (2)(cnt)

The number of occurrences of user-defined metrics in category 2 observed in the HTTP or XML traffic.

Custom metric (2)(sum)

The sum of all values of user-defined metrics in category 2 observed in the HTTP or XML traffic.

Custom metric (3)(avg)

The average value of user-defined metrics in category 3 observed in the HTTP or XML traffic.

Custom metric (3)(cnt)

The number of occurrences of user-defined metrics in category 3 observed in the HTTP or XML traffic.

Custom metric (3)(sum)

The sum of all values of user-defined metrics in category 3 observed in the HTTP or XML traffic.

Custom metric (4)(avg)

The average value of user-defined metrics in category 4 observed in the HTTP or XML traffic.

Custom metric (4)(cnt)

The number of occurrences of user-defined metrics in category 4 observed in the HTTP or XML traffic.

Custom metric (4)(sum)

The sum of all values of user-defined metrics in category 4 observed in the HTTP or XML traffic.

Custom metric (5)(avg)

The average value of user-defined metrics in category 5 observed in the HTTP or XML traffic.

Custom metric (5)(cnt)

The number of occurrences of user-defined metrics in category 5 observed in the HTTP or XML traffic.

Custom metric (5)(sum)

The sum of all values of user-defined metrics in category 5 observed in the HTTP or XML traffic.

Excluded operations

The number of operations for which the operation time was above a safety threshold. The term "operations" refers to operations in the context of the particular protocol, and can mean HTTP/HTTPS page loads, database queries, XML (transactional services) operations, Jolt transactions on a Tuxedo server, e-mails, DNS requests, Oracle Forms submissions, MQ operations, VoIP calls, MS Exchange operations, or SAP operations.

Failures (TCP)

The total number of operations that failed due to Connection refused or Connection establishment timeout errors.

Failures (application)

The number of operation attributes of all types set to be reported as an application failure.

Failures (total)

The total number of failures, that is all Failures (transport) + all Failures (TCP) + all Failures (application)

Failures (transport)

The number of operations that failed due to the problems in the transport layer. These include protocol errors, SSL alerts classified as a failure, incomplete responses selected be classified as failures.

HTTP client errors (4xx)

The sum of all HTTP client errors (4xx).

This includes 4 categories of errors (4xx), by default HTTP Unauthorized (401, 407) errors, HTTP Not Found (404) errors, custom client (4xx) errors and Other HTTP (4xx) errors. The contents of the first 3 categories can be configured by users.

However, there are two types of the 4XX errors that are of particular importance: errors 401 related to server-level authentication, and errors 404 indicating requests for non-existent content. These two error types are reported separately, by specific metrics.

  • 401 Unauthorized - Server reports this error when user's credentials supplied with request do not satisfy page access restrictions. The HTTP server layer, not the application layer, reports 401 errors. The AMD will report on "Unauthorized" errors only if server-level authentication has been configured. This is common practice for sites that are comfortable with very basic user access policies. Most commercial-grade applications do not rely on server-level authentication (e.g. most of online banking applications or online shopping), but rather authenticate users on the application layer. In such a case, even if authentication fails, the server will typically send 200 OK responses and authentication error information will be explained in page content. So this kind of error is not very common in commercial sites.

  • 404 Not Found - Server reports "Not Found" errors when it cannot fulfill client request for a resource. Usually it happens due to malformed URL, which directs to a non-existing page or image. Such a URL request may result from a user, who misspelled the URL, trying to access a URL that the user stored in his "Favorites" folder a long time ago, or some other mistake. Malformed URLs may also exist in invalid or incorrectly designed Web pages so the error will be reported by browsers trying to load such a page. Significant and constant number of these errors usually indicates that some pages on the server have design-related or link validation issues. In some cases, 404 errors result from the server overload. It is good practice to check whether the percentage of errors is load-related.

HTTP client errors - category 3 (default name)

The number of HTTP custom client errors (4xx). By default, there is no specific error type assigned here.

HTTP not found errors 404 (default name)

The number. These include the observed custom HTTP 404 Not found errors.

HTTP other client errors (4xx)

The number of HTTP other client errors (4xx).

There are four categories of HTTP client errors (4xx), of which three can be configured by users. By default, the first category includes HTTP Unauthorized (401, 407) errors, the second category - HTTP Not Found (404) errors. The third category contains no default error types assigned, and can be configured by a user. Finally, a group of HTTP Other (4xx) errors contains all errors that do not fall into any other client errors category.

The number is calculated based on the formula: [HTTP errors 4xx] - [HTTP Not Found errors 404] - [HTTP Not Authorized (401+ 407)] - [HTTP errors configured by user].

HTTP other server errors (5xx)

The number of HTTP server errors (5xx) that do not fall into categories 1 or 2 of custom HTTP server errors (5xx).

HTTP redirect time

The average amount of time that was spent between the time when a user went to a particular URL and the time this user was redirected to another URL and issued a request to that new URL. The HTTP redirect time refers to the transactions for which redirection actually took place.

HTTP server errors (5xx)

The number of observed HTTP server errors (5xx).

The response status codes 5xx indicate cases, in which the Web server is aware that there was a server error or it is incapable of performing the request. Such error presence usually means that the Web server does not function as intended. The following 5xx errors are defined by the HTTP protocol standards:

  • 500 Internal Server Error - The server encountered an unexpected condition, which prevented it from fulfilling the request.

  • 501 Not Implemented - The server does not support the functionality required to fulfill the request.

  • 502 Bad Gateway - The server received an invalid response from a back-end application server.

  • 503 Service Unavailable - The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.

  • 504 Gateway Timeout - The server did not receive response from a back-end application server.

  • 505 HTTP Version Not Supported - The server does not support the HTTP protocol version that was used in the request message.

HTTP server errors – category 1 (default name)

The number of custom HTTP server errors (5xx), category 1. By default, there are no specific error types assigned to this category.

HTTP server errors – category 2 (default name)

The number of custom HTTP server errors (5xx), category 2. By default, there are no specific error types assigned to this category.

HTTP server image time

This is the total amount of time it takes for images (non-HTML content) to be prepared for delivery.

HTTP unauthorized errors 401, 407 (default name)

The number of observed custom HTTP authentication related errors.

These include "HTTP 401 Unauthorized" and "HTTP 407 Proxy authentication required" errors.

HTTP servers generate errors "401 Unauthorized" in cases, when anonymous clients are not authorized to view the requested content and must provide authentication information in the WWW-Authenticate request header. The 401 errors are similar to "403 Forbidden" errors, however used when authentication is possible but it has failed or not yet been provided. The 407 error is basically similar to 401, but it indicates that the client should first authenticate with a proxy server.

The AMD will report these errors only if the server-level authentication has been configured. Simple and basic user access policies are common in Web sites that do not store user-sensitive and/or business critical information.

Most commercial-grade applications, based on HTTP, such as home banking applications or online shopping sites, rely on the application-level authentication rather than the server-level authentication. Such applications are designed in the way that even if the user authentication fails, the HTTP server usually sends the 200 OK response code and the authentication error message in the page content. Therefore, the 401 Unauthorized and 407 Proxy authentication required error codes are quite rare in commercial environments.

Hits

The number of subcomponents of error-free operations. Note that this metric is recorded at the time when the monitored operations are closed. In case of HTTP, it is when the whole page has been loaded. Compare "Hits (started)". For example, when the user issues an HTTP GET, a "Hit (started)" is reported immediately, whereas if a whole page is loaded and the operation is closed, it is reported as a "Hit".

Hits (started)

The number of subcomponents of operations. Unlike the "Hits" metric, "Hits (started)" is recorded immediately, not at the end of an operation. For example, when the user issues an HTTP GET, a "Hit (started)" is reported immediately, whereas if a whole page is loaded and the operation is closed, it is reported as a "Hit".

Idle sessions

The number of idle TCP sessions, that have not been active for a period of time longer than a predefined time-out time, 5 minutes by default.

Idle time

The part of the operation time spent between receiving a part of the response and requesting a subsequent part. It enables you to isolate the time taken by client from the time when the data was still being transmitted on the network

Incomplete Responses

The number of incomplete responses, that is partial and server aborted responses, as well as situations when a server did not respond to the request at all or responded in an unrecognizable way.

LAN-WAN byte ratio

The amount of compression performed and expressed as a percentage.

  • 100% for pass-through.

  • Greater than 100% if more bytes on the WAN side, including both pass-through and optimized traffic.

  • Less than 100% if fewer bytes on the WAN side, including both pass-through and optimized traffic.

Network performance

The percentage of total traffic that did not experience network-related problems (traffic in which the values of loss rate and RTT did not exceed configured thresholds).

Network performance affected bytes

The volume of TCP traffic that did experience network-related problems. The traffic measured here includes both directions of data transfer, to and from client, or downstream and upstream, but does NOT include bytes transferred internally within the site. By network-related problems we understand excessive RTT or Loss Rate: at any given moment, traffic is considered to be experiencing network-related problems if, at that particular time, the values of Loss Rate or RTT exceed pre-configured thresholds.

In situations when RTT measurements prove to be insufficient, ACK RTT may also become an additional criterion for determining network problems.

Network performance relevant bytes

The total volume of TCP traffic. Includes both directions of data transfer, to and from client, or downstream and upstream, but does NOT include bytes transferred internally within the site.

Network time

The time the network (between the user and the server) takes to deliver requests to the server and to deliver operation information back to the user. In other words, network time is the portion of the overall time that is due to the delivery time on the network.

Operation attributes (1)

The number of operation attributes of type 1, observed for the given software service.

Operation attributes (2)

The number of operation attributes of type 2, observed for the given software service.

Operation attributes (3)

The number of operation attributes of type 3, observed for the given software service.

Operation attributes (4)

The number of operation attributes of type 4, observed for the given software service.

Operation attributes (5)

The number of operation attributes of type 5, observed for the given software service.

Operation length

The number of packets that contained in an average operation.

Operation time

The time it took to complete an operation. The term "operation" refers to an operation in the context of a particular protocol, and can mean HTTP/HTTPS page loads, database queries, XML (transactional services) operations, Jolt transactions on a Tuxedo server, e-mails, DNS requests, Oracle Forms submissions, MQ operations, VoIP calls, MS Exchange operations, or SAP operations. Note that an operation can be split over several packets. For HTTP and HTTPS, it is equal to the redirect time plus the network time plus server HTTP time plus server think time.

Operations

The number of operations. The term "operations" refers to operations in the context of the particular protocol, and can mean HTTP/HTTPS page loads, database queries, XML (transactional services) operations, Jolt transactions on a Tuxedo server, e-mails, DNS requests, Oracle Forms submissions, MQ operations, VoIP calls, MS Exchange operations, or SAP operations.

Other SSL errors (default name)

SSL alerts other than those for SSL errors 1 and SSL errors 2.

Other time

Part of the operation time, calculated as Operation time - Server Time - Network Time - Idle time. For RUM sequence transactions, the other time is sum of the client response time and the application processing time.

Out of contract bytes

The number of bytes marked as Out-of-contract in the TOS field in the TCP header. This setting can signify that the data was sent over and above a certain preset limit.

Out of contract packets

The number of packets marked as Out-of-contract in the TOS field in the TCP header. This can signify that the data was sent over and above a certain preset limit.

Percentage of optimized traffic (bytes)

Indicates the traffic distribution in two separate branches: optimized traffic and passed-through traffic.

The higher the value, the more bytes are optimized.

Low values may indicate poorly configured optimization or optimization device overload.

RTT measurements

The number of RTT measurements. An RTT measurement occurs during every TCP handshake, so it provides some insight into the number of attempted TCP sessions, and the potential accuracy of the RTT measurements that are reported.

Redirect time

The average amount of time that was spent between the time when a user went to a particular URL and the time this user was redirected to another URL and issued a request to that new URL. The difference between Redirect Time and HTTP Redirect Time is that the former counts all operations, while the latter refers only to those operations for which redirection actually took place.

Request time

The time it took the client to send the HTTP request to the server (for example, by means of an HTTP GET or HTTP POST). Note: This time includes TCP connection setup time and SSL session setup time (if any). It starts when the client starts the TCP session on the server and ends when the server receives the whole request. Sometimes an operation is slow because of a big request rather than due to a large response.

Response messages

The total number of protocol-specific server responses. That includes both errors and other identifiable response strings, as configured in monitoring.

SSL conn. setup per operation

The time it took to establish an SSL connection between the client and the server, weighted per number of operations. For HTTP-based software services, a single operation means a single page.

SSL conn. setup per session

The time it took to establish an SSL connection between the client and the server.

SSL errors 1 (default name)

If not explicitly configured, general SSL alerts from the following list: 10,20,21,22,30,40,49,50,51.

SSL errors 2 (default name)

If not explicitly configured, general SSL alerts from the following list: 41,42,43,44,45,46,48.

Server ACK RTT

RTT measurement performed during ACK packet transmission, from server side of the operation. Also provided are minimum, maximum and standard deviation values.

Server ACK RTT measurements

These metrics keep track of how many RTT of Server ACK measurements were made. ACK measurement is performed during ACK packet transmission either from server or client side of the transaction.

Server RTT

The time it takes for a SYN packet (sent by a user) to travel from the AMD to a monitored server and back again. Also provided are minimum, maximum and standard deviation values.

graphical illustration
graphical illustration

Server TCP data packets

The total number of TCP packets sent by the servers, excluding the traffic control packets.

Server TCP data packets lost

The number of lost TCP data packets sent by the servers, excluding the traffic control packets. The number of lost TCP packets always regards the context of the counter, for example, an application, a client or any other entity.

Server bytes

The number of bytes sent by servers. The number includes headers.

Server not responding errors

The number of Server Not Responding errors. This category of errors applies when the client closes the TCP session with a RESET packet after the server has failed to respond for too long.

Server operation size

The size of a server operation. In HTTP and HTTPS (decrypted and non-decrypted), server operation size equals the operation size.

Server packets

The number of packets sent by the servers.

Server packets lost (AMD to client)

The number of packets sent by a server that were lost - between the AMD and the client - and needed to be retransmitted.

Server realized bandwidth

Server realized bandwidth refers to the actual transfer rate of server data when the transfer attempt occurred, and takes into account factors such as loss rate (retransmissions). Thus, it is the size of an actual transfer divided by the transfer time.

Server response time

This is the amount of time it takes for a server to provide its initial response to a user's operation request. Often servers will respond with some information quickly, before all the information is ready for delivery. Together with the server think time, the server response time sums to the overall server time. Note that if there was no think time recorded for the operation, it equals the server time.

Server retransmission timeouts

Number of times retransmission timeout occurred on server connection. Calculated only for AppFlow records collected by AMD from NetScaler.

Server session termination errors

The number of Server Session Termination errors. This category of errors applies when the server detects an error on the software service level and closes the TCP session with a RESET packet.

Server time

The time it took the server to produce a response for the given request.

Short aborts

The number of transactions stopped before timeout. For HTTP, this is the number of page loads software service manually stopped by the user by either clicking on the Stop or Refresh buttons or selecting another URL before 8 seconds of waiting for the page download (8 seconds is default). For XML, this is the number of transactions stopped before a threshold number of seconds of waiting (8 seconds is the default).

Slow operations

The number of operations for which the operation time was above a predefined threshold value. The term "operations" refers to operations in the context of the particular protocol, and can mean HTTP/HTTPS page loads, database queries, XML (transactional services) operations, Jolt transactions on a Tuxedo server, e-mails, DNS requests, Oracle Forms submissions, MQ operations, VoIP calls, MS Exchange operations, or SAP operations. Note that slow operations for SMB are not determined using the time threshold, but maximum and minimum realized bandwidth thresholds.

Slow operations (application design - # of components)

The number of slow operations caused by the number of components, which is one of the detailed reasons in the application design category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (application design - redirect time)

The number of slow operations caused by redirect time, which is one of the detailed reasons in the application design category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (application design - request size)

The number of slow operations caused by request size, which is one of the detailed reasons in the application design category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (application design - response size)

The number of slow operations caused by response size, which is one of the detailed reasons in the application design category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (client/3rd party)

The number of slow operations caused by client/3rd party category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (data center)

The number of slow operations caused by the data center category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (multiple reasons)

The number of slow operations caused by multiple reasons, that is when the algorithm was not able to determine one primary reason for slowness. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (network - latency)

The number of slow operations caused by latency, which is one of the detailed reasons in the network category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (network - loss rate)

The number of slow operations caused by loss rate, which is one of the detailed reasons in the network category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow operations (network - other)

The number of slow operations caused by other factors than latency or loss rate, which is one of the detailed reasons in the network category as calculated using the primary reason for slowness algorithm. Note that this includes only successful operations. Failures and aborted operations are not taken into account.

Slow user sessions

The number of client sessions, which contained at least one slow operations (page load for HTTP or HTTPS).

Standalone hits

The number of hits not associated with any operation, such as orphaned redirects, unauthorized hits, and discarded hits (no server response).

TCP SYN time

The time needed to establish a connection on the TCP/IP layer, that is, the average time it took to transfer SYN packets.

Total bytes

The number of all transmitted bytes (client + server).

Total bytes compression

The data optimization observed, expressed as a byte reduction and a percentage, where a lower byte count on the WAN side means a higher reduction:

  • 0% for pass-through.

  • Less than 0% if more bytes were observed on the WAN side, including both pass-through and optimized traffic.

  • Greater than 0% if fewer bytes were observed on the WAN side, including both pass-through and optimized traffic.

This metric should not exceed 100%.

Total bytes on LAN side

The sum of bytes (client's and server's) observed on the LAN side before network traffic is directed into the WAN Optimization Controller (WOC).

Total bytes on WAN side

The sum of bytes (client's and server's) observed on the WAN side after network traffic leaves the WAN Optimization Controller (WOC), including bytes that have been passed through and those that have been marked as optimized.

Transfer time

The average time it took the server to send a response to the client, averaged over all the operations in the monitoring interval.

Unique users

The number of unique users detected in the monitored traffic.

User sessions

The number of user HTTP sessions. The count can be identified by information contained in intercepted HTTP cookies or by HTTP authorization.

VoIP Jitter

VoIP average jitter measured by the probe, for both downstream and upstream traffic. Jitter is a variation in voice data transit delay, in milliseconds. In general, higher levels of jitter are more likely to occur on either slow or heavily congested links.

VoIP MOS

VoIP average Mean Opinion Score (MOS) rating of the call quality, for both downstream and upstream traffic.

VoIP R-factor

VoIP average R-factor value, for both downstream and upstream traffic. It is a transmission quality rating, with a typical range of 50-100. An R-Factor score is derived from multiple VoIP metrics, including latency, jitter, and loss.

VoIP RTCP Jitter

VoIP average jitter as reported by Real Time Transport Protocol (RTCP), for both downstream and upstream traffic. Jitter is a variation in voice data transit delay, in milliseconds. Higher levels of jitter are more likely to occur on either slow or heavily congested links.

VoIP delay

VoIP average networking delay, as reported by Real Time Transport Protocol (RTCP), measured for both downstream and upstream traffic.

VoIP loss rate

The percentage of VoIP packets lost or discarded that needed to be retransmitted, measured for both upstream and downstream traffic.

Zero window size events (client)

Client sets this in TCP header when it wants the other side to slow down with data transmission because it cannot keep up with the transmission speed. Indicates that receiving machine is busy with other tasks.

Zero window size events (server)

Zero window size events (server)