Performance Metrics
Performance Metrics
Performance metrics are the core data that you can use to monitor the performance of networks and applications, and to troubleshoot performance degradations. By default, all metrics are expressed as average values, taking into account all measurements done during the selected time period. Other aggregation models (Percentile 50, 75, 90 and 99) can be selected from the top left dropdown menu.
Network Probe Telemetry
POP Connectivity
The “POP Connectivity” metric corresponds to the Round Trip Time measured from the Enterprise Station or the NSClient to the Netskope POPs the Enterprise Station / the NSClient is connected to.
It corresponds to the time it takes to send a packet from an Enterprise Station / NSClient to a Netskope POP and get the response back.
Example of the RTT calculation using UDP (Network Probe test from an Enterprise Station)
In the context of Netskope Network Probe, RTT is the time elapsed between the following events:
- The Enterprise Station sends a Network Probe test to the Netskope POP
- The Netskope POP responds with an ICMP error message (Destination Unreachable – Port Unreachable) back to the Enterprise Station
In order to compute the RTT, Netskope takes all Network Probe tests as well as all possible paths into account and calculates the average value:
RTT = (∑RTT Network Probe tests) / #tests
In the example below, RTT = measure 1 for path 1-2-4-6 (100ms) + measure 2 for path 1-2-4-6 (120ms) + measure 1 for path 1-3-5-6 (80ms) + measure 2 for path 1-3-5-6 (100ms) / 4 = 100ms.
Packet loss
The “Packet loss” metric corresponds to the end-to-end packet loss measures from the Enterprise Station or the NSClient to the Netskope POPs the Enterprise Station / the NSClient is connected to.
Packet loss = #No response from the target (Netskope POP) / #Network Probe tests to the target (Netskope POP)
| Note:Depending on the Network Probe method used, the target may be reached or not. If the target is not reached, the packet loss takes the furthest discovered router into account. In normal operations, the Netskope POPs are always reachable through either ICMP or UDP. The method is configurable (for Network Probe tests issued from Enterprise Stations). |
Network Path Visualization
Packet Loss (Node Level)
Packet loss = #No response from the node / #Network Probe tests to the node.
Delay
Delay refers to the RTT calculation made at intermediate nodes level.
It corresponds to the time elapsed between the following events:
- The Enterprise Station sends a Network Probe test to the node
- The node responds with an ICMP error message (TTL Exceeded in Transit) back to the Enterprise Station
So this RTT value is calculated at each node level. This is computed based on all values from all Network Probe tests and all Enterprise Stations (in case multiple Enterprise stations share the same node in their respective network paths):
RTT = (∑RTT Network Probe tests from all Enterprise Stations) / #tests
Link Delay
The link delay refers to the network latency between two consecutive nodes in a network path.
It is calculated by subtracting the minimum value of RTT measured at two consecutive nodes level.
To explain how this delay is calculated, let’s take the following example:
The network delay introduced by the link between nodes 6 and 7 is calculated as follows:
- Amongst all RTT (Round Trip Time) values computed by Network Probe tests between the Enterprise Station and node 7, Netskope keeps the smallest value (MIN_RTT_7)
- Amongst all RTT values between the Enterprise Station and node 6, Netskope keeps also the smallest value (MIN_RTT_6)
- The network delay between node 6 and node 7 is then calculated by subtracting MIN_RTT_6 from the MIN_RTT_7 value, that is Delay = MIN_RTT_7 – MIN_RTT_6.
In some cases, depending on the router configuration (e.g. ICMP protocol handled with a lower priority) and status (temporary congestion), routers can send ICMP error messages quicker than others. In such circumstances, considering our previous example, node 7 may respond quicker than node 6, leading to a negative network delay value. In this case, the Netskope interface will not report any value on the network path visualization.
Packet Loss (Link Level)
The packet loss measurement at a link level corresponds to the average value of the packet loss (node level), taking into account all paths that took the route(s) traversing the link in question.
Path Length
The path length corresponds to the average number of hops between consecutive nodes/routers, from the Enterprise Station or NSClient to the target (Netskope POP).
App Probe Telemetry
Application Availability
The availability of an App Probe test target is the percentage of App Probe tests for which the target responded back to the NSClient within the 200-299 range or to the Enterprise Station within the configured response code range (this response code range is defined in the custom application definition).
An App Probe test error will always count as “unavailable service”.
Sites/Users to Netskope POPs
The following metrics are processed at the NSClient and/or Enterprise Station level.
DNS
The “DNS” metric corresponds to the time needed to resolve the App Probe test target FQDN (Fully Qualified Domain Name) into an IP address.
Connection
The “Connection” time from the sites/users to Netskope POPs section corresponds to the time spent by the NSClient/Enterprise Station to establish a TCP connection with the NSProxy.
TLS
The “TLS” time from the sites/users to Netskope POPs section corresponds to the time spent by the NSClient/Enterprise Station to perform the TLS handshake process with the NSProxy.
Inside Netskope POPs
The following metric is processed at the NSProxy level.
POP Transit Time
The POP Transit Time provides the total time spent within the NSProxy.
It is the addition of the “request transit time” and the “response transit time”. These are defined as follows:
- Request transit time
Time elapsed between the first byte of request reaching the NSProxy and this first byte of the request leaving the NSProxy
- Response transit time
Time elapsed between the first byte of response reaching the NSProxy and this first byte of response leaving the NSProxy
Netskope POPs to Applications
The following metrics are processed at the NSProxy level.
Connection
The “Connection” time from the Netskope POPs to Applications section corresponds to the time spent by the NSProxy to establish a TCP connection with the targeted server.
TLS
The “TLS” time from the Netskope POPs to Applications section corresponds to the time spent by the NSProxy to perform the TLS handshake process with the targeted server.
Server
The “Server” time corresponds to the time between the first byte of NSProxy request to the targeted server and the first byte of response received by the NSProxy.
This Server time is the main server performance indicator, as it mainly takes the server processing time into account. Note though that there is also one RTT (between the NSProxy and the server) included. So bad network conditions between the NSProxy and the server may also impact the Server time value.
End-to-end Measurements
The following metrics are processed at the NSClient and/or Enterprise Station level.
Redirects and Redirect
The “Redirects” metric provides the number of redirections that occurred before reaching the final target delivering the monitored application(s).
This metric can appear as a value or a range of values. For example, a range “0 – 5” indicates that amongst all App Probe tests considered, there were between 0 and 5 redirections.
The “Redirect” metric provides the time spent in all the redirections (so it does not include metrics related to testing the final server that delivers the application).
TTFB
The TTFB (Time To First Byte) corresponds to the time between the Enterprise Station / NSClient sending the HTTPS request (aka first byte of the request is sent) and when it receives the first byte of data payload (aka the response) from the NSProxy.
This TTFB is a good indicator of global application performance as its value is primarily affected by the:
- Network conditions
Degraded networks can lead to high latency or packet loss value, which in turn affects the TTFB by delaying the request and/or the response. - Network POPs
Slow transit time within Netskope POPs may impact the request and/or the response transmission over the network. - Server itself
The ability of the server to efficiently compute the request and send a response will directly affect the TTFB value.
TTLB
The TTLB (Time To Last Byte) corresponds to the time between the Enterprise Station / NSClient sending the HTTPS request (aka first byte of the request is sent) and when it receives the last byte of data payload (aka the response) from the NSProxy.
Data Transfer
The “Data Transfer” time corresponds to the time needed to transfer the full payload from the server to the Enterprise Station / NSClient.
Data Transfer = TTLB – TTFB
Duration
The “Duration” metric corresponds to the time taken for the whole App Probe test process to be processed and completed.
Transfer Size
The “Transfer size” corresponds to the total response payload transmitted over the network.
