How-to Debug Your CDN and Speed Up Your Website
Site speed is a critical factor in the success of any website, especially sites offering products or services for sale. However, slow-loading sites may also be pushed lower in Google rankings, making it more difficult for people to find them. The first content delivery networks focused primarily on performance, while the second generation of CDNs focused on both performance and availability. The latest generation offers amazing performance, advanced security, and availability that is virtually guaranteed. To achieve the greatest benefits from any CDN service, though, it is necessary to review reports regularly, address any issues found, and debug the service if you suspect it is not performing as it should. The following tools can help you with your debugging efforts.
DNS: Dig Your CNAME
For purposes of illustration, assume the following information.
• Your service domain is cdn.yourcompany.com.
• Your service identifier is 54321.r.cdnsun.net.
The service identifier in the example is a ready-to-use CDNsun domain that offers up your CDN content. If you want to use additional custom service domains, you will need to add a CNAME record for each to the configuration of your DNS. To verify the accuracy of the CNAME record, you can use the dig tool. At CDNsun, we offer an online dig tool, but you can also use the tool from the command line. Whichever method you use, the results returned should resemble the following.
• cdn.yourcompnay.com 21599 IN CNAME 54321.r.cdnsun.net
If the dig result does not include the CNAME record, then the record is either not set up correctly or not propagated. Please keep in mind that it can take as long as 48 hours for DNS configuration changes to propagate.
Curl Up With Static Content
Origin content must be accessible via HTTPS or HTTP protocol, and it has to return only 200 status codes. Although it can take a few minutes for a new CDN service to show up, if sufficient time has elapsed, you should be able to access CDN content. Assume that you have content that you cannot access at a URL named http://static.yourcompany.com/htdocs/images/image.jpeg.
We offer an online curl tool, but you can also use the command line. The results should look something like the following.
curl -I http://yourcompany.com/htdocs/images/image.jpeg
HTTP/2 200 OK
Date: Sun, 09 Dec 2018 05:21:32 GMT
Server: Apache
Last-Modified: Fri, 07 Dec 2018 01:10:38 GMT
If you are not getting a status code of 200, the issue will need to be fixed on your origin server. New origin settings may also require you to purge CDN content cached with the previous settings.
Dumping the RTMP Stream
The Linux RTMPDump tool allows you to check your CDN and origin streams. Note that video content may exist in either your origin storage or origin domain, but you can check either with curl.
Suppose the RTMP stream is at rtmp://54321.r.cdnsun.net/54321/_definst_/live
The command would be rtmpdump -o output.mp4 –rtmp rtmp://54321.r.cdnsun.net/54321/_definst_/live
An active stream should return something along the lines of the following as part of the RTMPDump output.
Connecting . . .
INFO: Connected . . .
Starting download
What Happens When the Origin Fails?
It is important to remember the difference between content that is pulled and content that is pushed. If you use CDN static pull, your CDN provider cannot detect or fix issues on your origin server. Both push and pull may work more or less normally for static content, but you may notice an impact on your cache-hit ratio.
CDN video pull and CDN video push as well as CDN live are not likely to function. In all likelihood, your CDN service will fail when your origin fails. This will probably leave you on your own to troubleshoot, debug and correct the issue or issues. Therefore, it is almost always best to push content whenever possible.
