Over a million developers have joined DZone.

Tracking Multi-CDN Performance Issues to DNS

Multiple CDNs gives you more resilience and potentially better performance. Read on to see the possible pitfalls with a multi-CDN strategy and how to address them.

· Performance Zone

Download Forrester’s “Vendor Landscape, Application Performance Management” report that examines the evolving role of APM as a key driver of customer satisfaction and business success, brought to you in partnership with BMC.

A multi-CDN service that combines multiple CDN providers into a single network is a common and effective way to speed up your web applications for users anywhere in the world. This strategy can also boost failover support in case one of the CDNs you’re using goes down.

But even a multi-CDN service is not immune from performance issues. Intermittent performance drops can and do happen even with this architecture. The likely culprit is a familiar but often ignored one—DNS.

First, let’s break down what typically happens in a multi-CDN setup:

  • When we access any domain (ex: tiqcdn.com), the browser checks its local cache for the DNS records.
  • If it does not have the information, a query is typically sent to the ISP’s DNS
  • Which in turn reaches out to the root server if the information is not already in the cache.
  • Typically, the Root Server would redirect the request to a GTLD server (.com in this case) if the info is not cached or if it has expired (depends on the TTL) and the GTLD server would return the Name Server info of the queried domain as shown below:

  • Next the DNS resolver queries one of the above-listed name servers depending on a number of factors, most importantly the Shortest Round Trip Time (RTT).
  • We can see that the domain (tiqcdn.com) has been C-Named to the multi-CDN provider “Cedexis”.
  • The DNS resolver again goes through the process of resolving the host name by going back to the root server if the information is not available in its cache as shown below.
  • The above query to the multi-CDN host is made and this is where the multi-CDN provider decides to which CDN the request should be routed to, based on some real-time performance metrics they capture internally. The decision can vary from one request to the other, which can be seen below:
  • The DNS Resolver will go through the process of resolving the Akamai host until it reaches the edge server which will eventually serve the content. The whole process may involve numerous queries as shown below:

    Now let’s take a look at Scenario 2 where the multi-CDN provider is redirecting the request to a different CDN – Highwinds

    The DNS resolver again has to go through the process of resolving this HOST. However, in this case we noticed that the Name Servers of Highwinds failed to respond:

    At Catchpoint, we have the option of failing a test at this point when all the available name servers fail to respond. In the real world, reattempts are made to the server if it fails the first time, so the users may not see a failure, but the performance will be hit badly.

    To summarize, a multi-CDN service can make your web applications faster and more reliable but is still not failsafe. Monitoring your application alone is simply not enough; DNS monitoring remains crucial.

    See Forrester’s Report, “Vendor Landscape, Application Performance Management” to identify the right vendor to help IT deliver better service at a lower cost, brought to you in partnership with BMC.


    Published at DZone with permission of Mehdi Daoudi, DZone MVB. See the original article here.

    Opinions expressed by DZone contributors are their own.

    The best of DZone straight to your inbox.

    Please provide a valid email address.

    Thanks for subscribing!

    Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}