In Userscript.org and Amazon S3, Jesse Andrews describes how he moved all of his static content from his own server over to S3. Jesse set up the virtual hosting, moved over all of the content (using S3 Fox no less), and had everything up and running inside of 15 minutes. As he notes "it took longer to write this post than it did to do the conversion."
Userscripts.org isn't some quiet site with little or no traffic. As the primary repository for Greasemonkey scripts, it is quite busy -- Jesse says that they handled 24 million requests for 307GB of static content in the last two months alone.
Jesse asked his friends to try out the new version side-by-side with the old one. In this unscientific and somewhat subjective test, the new version (using S3) was unanimously judged to be faster.
By the way, be sure to browse the items tagged with Amazon on the site. You'll find my old favorite Book Burro (also written by Jesse) and lots of other cool stuff.
But wait, there's more!
Casey Muller wrote a really nice guide, including code for an s3commit script (to copy assets to S3) on Serving the Rails Public Directory out of S3. Casey is one of the developers of jamglue, currently in beta and serving up its content from S3.
-- Jeff;


Very cool. Good story!
Posted by: Marshall Kirkpatrick | November 21, 2006 at 09:14 AM
If anyone else is doing this in a ruby on rails app, make sure to check out config.action_controller.asset_host. I used it to do the same thing, except you don't have to go around changing all your links, and you can then turn off using S3 with a one-line change:
http://casey0.com/archive/2006/October/How_to_serve_the_rails_public_directory_out_of_S3.html
Posted by: Casey Maloney Rosales Muller | November 21, 2006 at 12:36 PM
I have written a rails plugin that does something similar except it expands upon the concept by using S3 as a cache store. So not only can I use S3 to serve my public directory using the techniques above, I cache fragments of my site (the database-driven pieces) at S3 using my S3Cache plugin. Whenever a record changes, all the cached fragments effected by that record change are updated at S3. So effectively I can serve up most of my site at S3, yet still be a database driven site.
I've been using it locally and can't tell much of a difference in performance (except if S3 is acting spotty like it was a couple of weeks ago). I plan to use it for my new site that will launch soon.
If anyone is interested in testing my S3Cache plugin, and preferably has some bits of their site already using fragment caching, then I can email them the plugin to test out. After some others test it, I'll release it into the wild.
Posted by: Steve Odom | November 22, 2006 at 08:54 AM
Akamai for the rest of us. Nice.!
Posted by: Ansel | December 13, 2006 at 11:52 AM