Help diagnose network problems, or rule them out quickly.
For teams concerned with how availability and delivery times impact what the customer does, feels and experiences the SV-Trace Route Management feature uses intelligence to provide you with instant feedback on the likelihood of network errors as root causes.
SV-Trace Route Reporting is used to highlight when journey performance is being impacted by problems at a network/CDN level, and to diagnose these issues automatically and pro actively.
SV- Trace Route Reporting saves vital investigation time for technical teams by providing an insight into whether a problem results from internal or external network factors, and whether or not it is under the team’s direct control, reducing frustration.
More information on the cause of the error and expected resolution can also be provided to eCommerce, Marketing and Customer Service Teams who may need to provide extra help, information and support to users experiencing issues.
Comparison of current connect time with typical network performance is also provided by server, along with details on average connect time, standard deviation and packet loss against configurable thresholds for intermediate hops.
Uncovering The Source
Variable performance of the networks and internet in different geographical locations can often be the source of problems. Support teams need to be able to quickly identify where in the network the slowdown occurred as the data “hops around” the internet to get to its destination.
Being able view a the traceroute whenever a sample returns on Error or Cutoff enables diagnosis of routing and understanding of how that relates to the issue. The ability to recall the traceroute for any given error sample will also help with trend analysis and in-depth investigation over the long term.
Live Network Analysis
After each step of every Dynamic User Journey the SV-Trace Route Manager will analyse the TCP Connection times for all servers that are involved in that Step and compare their Connection times in the step, with that of their average over the previous few hours, and against a set performance threshold.
If the servers have a Connect time that is as expected the Sample date when viewed in the Portal will state that fact so that the user does not need to worry about dong any further network troubleshooting.
If, on the other hand, the analysis shows that a server has a significantly slower TCP Connect time then the previous few hours this is an indication of a network problem.
It will also show the IP address of the server in question, making it easy to see if your CDN is redirecting to servers in other countries from the IP addresses.
Triggering A Network Test
If a user journey encounters an error or slowdown it is helpful to have some extra diagnosis to see if the problem is network based in the first instance, and, if it is, whether that problem is occuring somewhere that the technical team have access to or control over. When the SciVisum engine has detected that a server in a Dynamic Journey Step has a significantly slower Connect time a network test is triggered.
This test will use MTR (MyTraceRoute), which is widely used as a measure of network problems.
The results of the MTR will be analysed, and where they exceed a given threshold this extra diagnosis will be shown in the SciVisum portal for that sample, ranked by percentage increase over the average.
If an issue with network performance speed affected the sample it will be shown in the new Network Performance Box, along with comparison data on server connect time and MTR. MTR is a network diagnostic tool that combines the the functionality of the ‘traceroute’ and ‘ping’ programs.
A message in green text will tell you if no network issue could be identified as the cause of an issue, or if connect time for the sample was average and so MTR was not executed.
- Tests indicate no network error.
A message in red text will tell you if a network issue was identified as a potential cause and the Server Connect time table and MTR tables will be appear.
- Tests indicate potential network error. Connect time is not typical. MTR executed.
Real Time Alerting
The automatic diagnosis information is included in the body of an Alert email, if an Alert is triggered due to Journey slowness or error.
This enables the support team to immediately focus their investigations in the right direction, provide the right information to colleagues, or know whether it is out of their control.
SciVisum alerts can be customised to suit both team and individuals roles, practices and position in the company workflow. Alerting can be set at not only the level of the individual user (who gets alerted for which types of issues and how they receive those alerts) but at what stage in the process a person is brought into the alert cycle if a problem escalates so that people are not getting redundant messages and losing important notifications.
Understanding network routes can reduce frustration and time spent investigating seemingly mysterious results. If your CDN provider arbitrarily starts to direct your domain to servers in Spain say, not England,then the extra latency would increase the connect time. Not knowing this could lead to many fruitless hours of searching for other reasons for slowdown.
A Single Point of Truth
Having proof of the network performance during period of error or slowdown can also make discussions on budget IT investment discussions, and prioritisation of support, developer and customer services strategy much more productive when based on hard evidence.
The common, intuitive user interface in the reports allows non-technical staff to immediately see the important top level information while enabling examination of the root cause of the problem by technical staff..
Cross departmental collaboration is enabled as IT, Operations,Sales and Marketing are provided with all relevant information needed to solve problems, make key strategic decisions and improve performance.
Where connect time is not typical and an MTR test is executed the following information will be provided:
- Server Connect by IP address time against the average
- Marking where connect time variance thresholds are exceeded
- The server names and addresses used by this sample
- The connect time taken by this server/IP address for this sample
- The typical connect time taken by this server/IP address for this sample
- Average connect time, standard deviation and packet loss for individual hops