Posts Tagged ‘s3’

Custom Amazon S3 URLs

Friday, May 16th, 2008

Quick tip for those considering Amazon S3: use a CNAME to make it look like your server is hosting the files.  For instance:

http://media.rssmeme.com/screen.css

That file is actually served by Amazon.  I have a CNAME set (media.rssmeme.com CNAME media.rssmeme.com.s3.amazonaws.com).  If someone comes out with a new product (or I decide to host the files myself) someday then it will be easy to change without changing URLs.

Note: your Amazon S3 bucket name must exactly match your hostname.  So I needed to have a bucket media.rssmeme.com first; I couldn’t use my old rssmeme bucket.

RSSmeme humming along; Curse you FriendFeed Stats!

Monday, May 5th, 2008

Here are some steps I’ve taken towards delivering a more reliable RSSmeme:

  1. All static files are being served by S3.  My server is set to redirect any requests to static files (like the widget) to the file on S3.  This means that if RSSmeme slows down and you have the widget installed; your site will not be affected.  Occasionaly S3 has a breakdown; if you are concerned with that affecting your site then please install the FeedBurner FeedFlare instead.  It is just as easy and the only way it will slow your site is if FeedBurner’s servers slow down (which I find highly unlikely).
  2. The real culprit here wasn’t entirely static files.  It was FriendFeed Stats.  The global statistics page was tying up an apache process for a long time while it calculated the results.  My server doesn’t have much memory so stealing an apache process is a very big deal.  Imagine 10 of you hitting the same global FriendFeed Stats page with an unprimed cache?  All of my apache processes get stuck, other users get angry, and chaos ensues.  So I’ve disabled the global statistics pages.  All user specific pages will continue to work.
  3. Over 250 different IPs (all requesting bogus URLs clearly trying to get access to my server) have been dropped using iptables.  I still need to figure out a better way to automate this process.  I think if an IP frequently requests a URL that results in a 404 then we can safely drop them instead of wasting time processing their requests.

Again; I’m sorry!  But things are much better now.