views:

229

answers:

1

I'm designing a web application to support use of a CDN in the future.

Two options I've considered:

  1. Use domain aliasing for static content on the site, including CSS, JS, and some images.
  2. Use "edge side includes" to designate static content regions.

(1) is simpler and I've implemented it before. For example, we would prefix each IMG src with http://images1.mysite.com/, and then later update the corresponding DNS to use the CDN. The drawback I've heard from users of our internal "pre-production" site is that they would have to push the images to images1.mysite.com to preview their changes internally -- ideally, files would not get pushed to images1.mysite.com until they're ready for production. (NOTE - hosts file changes and DNS tricks are not an option here.)

Instead, they would like to simply use relative or absolute paths for static content. e.g. /images/myimage.gif

(2) is not as familiar to me and I would like more info. Would this allow our "pre-production" team to reference static content with a relative path in "pre-production environment" and yet have it work with the CDN in production without HTML modifications?

Could someone compare the two options, in terms of ease of development, flexibility, and cost?

+1  A: 

Here's a variation on the second option to consider.

Leave relative image URLs alone in your HTML. On your production server, have image requests return a server-side redirect to the image location on the CDN. This generates marginally more traffic than the other techniques, but it generates an access log entry for each image hit, keeps your HTML and site structure simple, factors specific CDN dependencies out of your site source, and lets you enable, disable or switch CDN-based image service on the fly.

If you are using a demand-pulled CDN such as Coral, you also need to ensure that requests either issued by or declined by the CDN are served directly from your production server. See Using CoralCDN as a server operator for more information on this technique.

Jeffrey Hantin
Please Note: CoralCDN has pretty bad response times than serving from your own webserver. I guess that's the case from other parts of the world too. It is probably (only) good option when you get spikes but coral takes the load. Think of Coral for reliability - not performance.
mixdev
I was mostly using Coral as an example since if your code is correct "It Just Works" -- it may be relatively slow but there's no fuss, muss, forms to fill or bills to pay, which is good if you're doing proof of concept work.
Jeffrey Hantin