Recently, we expanded a client’s web site to targeted users in the Asia/Pacific region. Months earlier, this same site began targeting users in both Europe and Australia. With the site hosted from the United States, we knew there would be network latency and node path issues causing performance degradation to these regions. Our first step in analyzing this problem was to implement a monitoring tool that would allow us to selectively gather web site stats from targeted areas of the world. So we configured Neustar Webmetrics performance and monitoring services to generate targeted performance statics in the regions of the world that we were interested in. This service is great, it offers a plethora of monitoring features for analysis. After running the monitoring service for several weeks, we were able to analyze the data and see performance patterns by city. The analysis showed an overall performance degradation in these regions of between 20% to 700%. With China having the worst performance at 700%. Now , we will take this information and use as a baseline against our CDN implementation. Next, we needed to implement a CDN solution. There are many CDNs to choose from with varying features and price points, we selected CacheFly for its overall performance rating. One thing to consider when implementing a CDN is what type of content will be delivered from the CDN. In our case, the web site is dynamic, meaning content is dynamically served for each page. So we are interested in using the CDN for images, documents, CSS files, and script files. Next, we need to change the references to these file types within the web site. Within our CMS, we were able to easily map these references to point to our new CDN. Depending on how your web site is setup these may be more cumbersome. There are several ways to implement file storage on a CDN. One is to ftp content to the CDN and let it replicate out to its edge servers. This can be time consuming if the stored content changes frequently. The other is to configure the CDN to use a reverse proxy. When this technique in configured, the CDN looks first in its cache for the requested file, if not present then it pulls (and caches) the requested content from the originating web site. Within our CDN configuration, we setup a reverse proxy and a TTL (time to live) of one week. A TTL tells the CDN how long to cache a piece of content before refreshing from the original site.
Now that we have implemented our CDN solution, we want to test the performance of the site. Using our monitoring service, we execute the same performance plan used originally to gather a new set of stats. After reviewing the stats, we found that the performance in the US alone increased by 40%. Outside the US, performance were up a minimum of 60% from the original timings. Our largest gains were in China, where originally timing were 700% slowing than the US and are now just 200% of the new US timings. Overall, we had a significant increase in web site response time for little cost and effort.