[consulting] CDN question and recommendation (Long)

Mark Schoonover mark at thetajoin.com
Tue Dec 15 04:51:02 UTC 2009


Christian,

You've received some great advice on the benefits to using a CDN. CDNs
are great for solving two problems, nearly unlimited storage, and
scalability of accessing static content. CDNs also introduce a few
drawbacks too. Like most things, it all depends.

I've done several CDN integrations with Drupal 6, and what I've learned
is it greatly depends on what content you need on a CDN. If your client
is creating regular page/story type content, all of their static content
is referenced by URL, you can configure Drupal to use a CDN without
installing any additional modules. I've mainly used Amazon S3 and
Cloudfront, but this approach should work with just about any CDN you're
interested in using.

Amazon S3 allows you to create a bucket to store your files, then use
something like S3Fox to batch upload your static content to S3. By
setting the rights to this bucket to public read, your client can simply
use the bucket URL to access those files. Granted, the bucket URL
created by S3 is rather ugly, but there's a way to make it look like you
have your own private CDN. Create your top level bucket something like
cdn.example.com. S3 requires all top level buckets to be unique across
all of S3, so you're pretty much guaranteed that this bucket is
available. Within the cdn.example.com bucket, you can create other
buckets - say files. Using an S3 file transfer program, your client can
upload their static content to this files bucket, much like they'd
upload to their Drupal server. Be sure the rights are public read to the
files bucket too. If you have access to configure DNS, create a CNAME
record that matches your top-level bucket: cdn.example.com that points
to s3.amazonaws.com. Now, when your client wants to put content on their
Drupal site that accesses the CDN, the URL would be
http://cdn.example.com/files/image.jgp, etc. With this approach, there
are no extra modules to be installed. 

<commercialcontent>
This is how I did the home page for a client extranet -
http://www.clear-images-photography.com . The photo of the homes is on
S3, and when creating the homepage, I used the URL
http://cdn.clear-images-photography.com/IslandHome.jpg. That particular
photo is only 410K, but others range from 1MB-1.5MB, to give you an idea
of why a CDN was the solution for this particular client.
</commercialcontent>

In order to use Cloudfront, you need to create a distribution of your S3
bucket, and use that URL instead. You can do the same CNAME trick too
because Cloudfront URLs are even uglier: a1cf92tbccle8s.cloudfront.net.
I've used cf.example.com to use Cloudfront. There are some drawbacks to
Cloudfront though. First, and probably most important, is that
CloudFront only keeps your content around for 24 hours after the last
time it was accessed. If a request comes in for content that has been
removed, you'll be charged to copy it from your S3 bucket again. This
may/may not be an issue for you if the site is busy as Cloudfront will
keep your static content available. The other thing to be aware of using
Cloudfront is that it's read only. You can't upload to it, only to your
S3 bucket, then are charged to copy to Cloudfront. Cloudfront doesn't
handle revisions well either - meaning if you upload mytopsong.mp3, make
changes to that mp3, and reupload using that same filename, Cloudfront
won't recognize that the file has changed unless it expires. The big
plus for Cloudfront is that there are many more datacenters supporting
it than S3.

If your client is going to use the imagecache CCK field to attach photos
to content, you'll probably want to serve thumbnails, etc from your CDN
too. The Cloudfront module can do this for you, pretty much automating
the process. I'm finishing up a project using the Cloudfront module, so
I really don't have much to add other than you need to be comfortable
making changes to settings.php, your theme's template.php file, and
configuring cron. Going this route, all S3/Cloudfront access is handled
by the Cloudfront module, so uploading content is handled at the Drupal
server, not outside. Your client may like this approach better, but the
Cloudfront module only supports images.

The Media Mover module also supports S3 integration according to the
docs.


Regards,
Mark Schoonover

--
http://www.thetajoin.com - The Drupal Hosting & Performance Company
Email: mark at thetajoin.com :: Voice: 619-928-4473 :: Fax: 619-374-3130



On Mon, 14 Dec 2009 08:55 -0500, "Christian Pearce"
<christian at pearcec.com> wrote:

  I have a potential customer that is going to have traffic from
  around the world.  It is my understanding a CDN will ease a
  lot of the pain while using the site.  First is this true?
  Second I plan on using this module
  [1]http://drupal.org/project/cdn, I imagine origin pull is
  going to be the best method.  Does anyone have experience
  using this?  Can you make a recommendation for a particular
  service to use?
  --
  Christian

References

1. http://drupal.org/project/cdn


More information about the consulting mailing list