CDN Monitoring to enhance “Client Experience”: Many interactive agencies seek to improve their “client experience” by constantly improving the “user’s experience” of their clients’ websites. One way that interactive agencies increasingly do this is to use Content Delivery Networks (CDNs) for faster delivery of the online content they have developed for clients. The use of CDNs allows interactive agencies to position online media, such that client website and web applications load faster for a better user experience, and improved website “results”, such as – impressions, conversions, and online sales.
However, use of CDNs is not without risk for both interactive agencies and their clients. By using a CDN, the interactive agency is also losing some insight into the performance of/and direct control over the online content. In fact, several issues can develop within a CDN that adversely affects online content and the websites that interactive agency’s produce for clients. As a result of these issues, the interactive agency’s relationship with its clients can suffer. However, when external monitoring is in place the interactive agency maintains insights into performance issues that occur to online content positioned on a CDN network and therefore can better serve its clients.
Issues facing Interactive Agencies using CDNs
When using or moving to a CDN on behalf of a client, interactive agencies are addressing several client-related factors as well as technology-related factors. Specifically, when an interactive agency recommends the use of a CDN for client content the interactive agency needs to both test the speed of CDN multimedia content when the CDN is set-up as well as monitor the delivery of the clients CDN content on an ongoing basis. For while a CDN may claim certain performance metrics for their network, without a third-party monitoring service it is difficult to prove the cause of issues that affect CDN-based or enforce Service Level Agreements (SLAs) with CDNs. Notably, as an interactive agency starts using a CDN to deliver content several performance metrics need to be addressed as the process moves along from initial evaluation and testing of the CDN to deliver client content, as well as ongoing use of a CDN, specifically:
- Starting with a CDN: Monitoring CDN-based content from multiple points of presence can provide metrics that serve as “proof of concept” for moving the client’s content to a CDN network. Using multi-point monitoring will provide clear data on the increased speed of CDN-based content delivery and improved website user experience. In turn, this will allow the interactive agency to quantify the value of using a CDN-based content delivery system for its clients.
- Comparing CDNs: In fact, multi-point external monitoring helps an interactive agency compare competing CDNs cost/performance to determine which CDN is able to best serve a client’s specific circumstances.
- Enforcing CDN SLAs: A CDN includes many geographically spread CDN nodes (content hosting servers). Some CDNs have node redundancy built in, others do not. External monitoring can detect if a specific CDN node is having problems. External monitoring will help determine if an “issue” is related to the CDN node itself or to broader network issues (such as, latency). This information is important to have from an external perspective in order to enforce Service Level Agreement (SLA).
- Managing CDN content: Is the content being served from the CDN to the webpage correct? Many interactive agencies have huge amounts of CDN-based content. External monitoring can determine if the multimedia content originating from the CDN is correct, or if the CDN-based content has gotten out of synch with the destination webpage.
- Real-time CDN performance and CDN-based content performance: What is the performance of the content being served from CDN nodes as reported from multiple monitoring points-of-presence? Monitoring data is used to quantify the user experience of end users located in different areas. Specifically, each monitoring location can provide data points, such as: CDN node response time, content load time, and pinpoint error conditions associated with content served from the CDN (such as “Image not found, Not able to Connect etc…).
CDN Monitoring in Action
Successful performance monitoring of a webpage using CDN-based content means employing a comprehensive approach, specifically: monitoring the webpage from across multiple networks (such as, Global Crossing, Sprint, Level 3 etc…), monitoring for Domain Name Server (DNS) resolution, network connectivity, and content availability.
1. DNS Resolution: This resolution (translation of a domain name to an IP address) occurs when an end-user tries to access content from a CDN node, and the name of the CDN has not been previously cached.
The NBA.COM website serves as a good example. NBA.com references a number of CDN-based images. A DNS Trace in Exhibit A (below) reveals a relatively long and complex DNS structure. This type of DNS structure ensures good load balancing and performance. However, all of the DNS servers noted in the traceroute must also be online for the CDN content to be served to the webpage in a timely fashion. For example, if any of the DNS servers fail or slow down, then the end-client server is likely to need additional time to resolve the DNS name.
As shown by Exhibit A, a properly constructed CDN monitoring service provides key data points regarding the amount of time it takes for DNS resolution. Also, proper CDN monitoring never caches DNS names, because by not caching DNS names the monitoring service ensures that a DNS resolution is performed with each test. Finally, executing CDN monitoring from multiple points located over a variety of worldwide internet backbone networks and geographically distributed monitoring locations ensures that there are no delays due to DNS outages.
2. Connectivity is very important in CDNs. Connectivity ensures that a end-user requesting an image in Australia is not sent to a CDN node host in the USA. This kind of re-routing would defeat the purpose of CDN (improved load times and user experience). A CDN monitoring service will ensure that there is a minimal amount of network latency (delay) from an end-user’s geographic location to a specific node in a CDN. A CDN monitoring service utilizes a worldwide network of monitoring locations to perform network traceroutes to CDN nodes from multiple locations, in order to ensure the fastest routing and minimum network latency. For example Exhibit B (below) shows traceroutes originating from several of Dotcom-Monitor’s worldwide monitoring locations to the CDN. Exhibit B demonstrates a CDN with fast routing—where an end-user on each continent is directed to the content located on the closest CDN node within a few network hops away. The monitoring service will also measure latency between the monitoring location and the CDN node and provide alerts when latency exceeds a threshold.
3. Content Availability is important, especially in Web 2.0 websites that use CDN as distribution media. A website may have dozen or more providers and pull content from multiple sources. To ensure a positive end-user browser experience, it is necessary to ensure that all the content is present, not missing and delivered in timely fashion. As webpages increasingly rely on browser-generated content and user-experience becomes key, a monitoring service must load the page in the browser and provide a breakdown by webpage elements, to make sure that no elements are missing and everything loads properly. For example: a delay in loading a java script file, may result in the delayed loading of a video or of a company logo. A CDN monitoring service provides a breakdown by individual webpage element (.gifs, .css, Ajax etc…) as shown in Exhibit C (below). The resulting waterfall chart pinpoints where problems causing increased webpage load times.
CDN Monitoring Services: The type of monitoring service used to conduct CDN-monitoring can vary based on the type of website, type of content, data points needed, “level’ of monitoring needed, and budget.
There are several levels of Dotcom-Monitor services available for conducting varying levels of CDN testing and ongoing monitoring to address a variety of client types and client needs during different stages of the CDN process. For example, an interactive agency could use standard HTTP/S monitoring to do an initial comparison of CDNs during evaluation, and then utilize UserView Monitoring™ to conduct ongoing website monitoring of a client’s complex Web 2.0 content being served by a CDN.
The Results of CDN Monitoring
CDNs, like other networks, experience change and adjustments that can affect client content. By using a Dotcom-Monitor CDN monitoring solution an interactive agency will be able to accomplish several objections that help to improve the client relationship, client retention, and performance of client websites. Specifically an interactive agency will be able to:
- Quantify the value proposition of CDNs for its clients.
- Compare competing CDN service providers on behalf of its clients
- Respond quickly be alerted to and identify CDN and CDN-based content issues (often before a client is ever aware of the issue)
- Solve CDN and CDN content issues
- Maintain a focus on its core business mission of providing services to its client
- Provide answers to its clients when CDN-based content issues occur by using the data points gathered, error codes generated, and coordinating with Dotcom-Monitor Support.
- Enforce Service Level Agreement (SLA) parameters on behalf of their clients with the CDN using the performance report SLA report data gathered by Dotcom-Monitor.
Exhibit A:
Traceroute: Tracing DNS to cdn.eyewonder.com
1 A.ROOT-SERVERS.NET [198.41.0.4]: Class=IN Type=NS
2 K.GTLD-SERVERS.NET [192.52.178.30]: Class=IN Type=NS
3 ns2.dnsmadeeasy.com [208.80.126.2]: Class=IN Type=NS
4 eyewond.vo.llnwd.net: Class=IN Type=CNAME
5 A.ROOT-SERVERS.NET [198.41.0.4]: Class=IN Type=NS
6 B.GTLD-SERVERS.NET [192.33.14.30]: Class=IN Type=NS
7 dns13.llnwd.net [69.28.143.13]: Class=IN Type=NS
8 eyewond.vo.llnwd.net [208.111.168.7]: Class=IN Type=A
9 eyewond.vo.llnwd.net [208.111.168.6]: Class=IN Type=A
10 dns14.llnwd.net [69.28.143.14]: Class=IN Type=NS
11 eyewond.vo.llnwd.net [208.111.168.7]: Class=IN Type=A
12 eyewond.vo.llnwd.net [208.111.168.6]: Class=IN Type=A
13 dns12.llnwd.net [69.28.143.12]: Class=IN Type=NS
14 eyewond.vo.llnwd.net [208.111.168.6]: Class=IN Type=A
15 eyewond.vo.llnwd.net [208.111.168.7]: Class=IN Type=A
16 dns11.llnwd.net [69.28.143.11]: Class=IN Type=NS
17 eyewond.vo.llnwd.net [208.111.168.7]: Class=IN Type=A
18 eyewond.vo.llnwd.net [208.111.168.6]: Class=IN Type=A
19 A.ROOT-SERVERS.NET [198.41.0.4]: Class=IN Type=NS
20 M.GTLD-SERVERS.NET [192.55.83.30]: Class=IN Type=NS
21 dns13.llnwd.net [69.28.143.13]: Class=IN Type=NS
22 dns11.llnwd.net: Class=IN Type=SOA
23 dns14.llnwd.net [69.28.143.14]: Class=IN Type=NS
24 dns11.llnwd.net: Class=IN Type=SOA
25 dns12.llnwd.net [69.28.143.12]: Class=IN Type=NS
26 dns11.llnwd.net: Class=IN Type=SOA
27 dns11.llnwd.net [69.28.143.11]: Class=IN Type=NS
28 dns11.llnwd.net: Class=IN Type=SOA
29 ns0.dnsmadeeasy.com [208.94.148.2]: Class=IN Type=NS
30 eyewond.vo.llnwd.net: Class=IN Type=CNAME
31 ns3.dnsmadeeasy.com [208.80.125.2]: Class=IN Type=NS
32 eyewond.vo.llnwd.net: Class=IN Type=CNAME
33 ns4.dnsmadeeasy.com [208.80.127.2]: Class=IN Type=NS
34 eyewond.vo.llnwd.net: Class=IN Type=CNAME
35 ns1.dnsmadeeasy.com [208.80.124.2]: Class=IN Type=NS
36 eyewond.vo.llnwd.net: Class=IN Type=CNAME
37 A.ROOT-SERVERS.NET [198.41.0.4]: Class=IN Type=NS
38 J.GTLD-SERVERS.NET [192.48.79.30]: Class=IN Type=NS
39 ns2.dnsmadeeasy.com [208.80.126.2]: Class=IN Type=NS
40 eyewond.vo.llnwd.net: Class=IN Type=CNAME
41 ns0.dnsmadeeasy.com [208.94.148.2]: Class=IN Type=NS
42 eyewond.vo.llnwd.net: Class=IN Type=CNAME
43 ns3.dnsmadeeasy.com [208.80.125.2]: Class=IN Type=NS
44 eyewond.vo.llnwd.net: Class=IN Type=CNAME
45 ns4.dnsmadeeasy.com [208.80.127.2]: Class=IN Type=NS
46 eyewond.vo.llnwd.net: Class=IN Type=CNAME
47 ns1.dnsmadeeasy.com [208.80.124.2]: Class=IN Type=NS
48 eyewond.vo.llnwd.net: Class=IN Type=CNAME
Trace complete.
Exhibit B:
From MN, USA:
Tracing route to cdn.eyewonder.com [208.111.168.6] 1 <10 ms <10 ms <10 ms 207.250.234.1 [207.250.234.1] 2 <10 ms <10 ms <10 ms 207-250-148-109.static.twtelecom.net [207.250.148.109] 3 15 ms <10 ms 15 ms chi2-pr1-ge-7-1-0-0.us.twtelecom.net [66.192.243.142] 4 15 ms 31 ms <10 ms tge7-1.fr3.ord.llnw.net [69.28.172.41] 5 15 ms 15 ms 15 ms cdn-208-111-168-6.ord.llnw.net [208.111.168.6]
From Frankfurt, Germany:
Tracing route to cdn.eyewonder.com [87.248.217.254]
1 <10 ms <10 ms <10 ms 83.243.81.1 [83.243.81.1]
2 <10 ms <10 ms <10 ms tng.decix.as31530.net [89.106.64.142]
3 15 ms <10 ms <10 ms 80.81.192.221 [80.81.192.221]
4 <10 ms <10 ms <10 ms cdn-87-248-217-254.frf.llnw.net [87.248.217.254]
From Sydney, Australia:
Tracing route to cdn.eyewonder.com [117.121.253.254]
1 <10 ms <10 ms <10 ms 202.157.178.193 [202.157.178.193]
2 <10 ms <10 ms <10 ms 210.80.173.113 [210.80.173.113]
3 15 ms 15 ms <10 ms 210.80.33.85 [210.80.33.85]
4 <10 ms <10 ms <10 ms 210.80.32.218 [210.80.32.218]
5 <10 ms <10 ms <10 ms gigabitethernet3-21.chw51.sydney.telstra.net [139.130.43.97]
6 <10 ms <10 ms <10 ms tengige0-1-0-0.chw-core2.sydney.telstra.net [203.50.20.129]
7 <10 ms 15 ms <10 ms Bundle-Ether1.chw48.Sydney.telstra.net [203.50.6.154]
8 <10 ms 15 ms 15 ms bundle-ether2.ken39.sydney.telstra.net [203.50.6.182]
9 171 ms 171 ms 187 ms tge5-1.fr3.syd.llnw.net [117.121.252.33]
10 187 ms 171 ms 203 ms cdn-117-121-253-254.syd.llnw.net [117.121.253.254]
Exhibit C:
