Jon’s Tumblr Thing-y

A couple folks asked about the hosting/set up for the MarryBacon site, so here’s bit of nerdery for anyone who cares.

How to Build a Site That Will Stay Up When Introduced to the World in a Super Bowl Commercial

Step 0: Hire astonishingly good designers and devs to build it.

Step 1: Keep it simple. Like, really simple. The site we built is essentially a single static semantic HTML file. Nothing is dynamically generated. It never hits a database. All the fancy-pants div-moving and opening is done through javascript wizardry.

Step 2: Use a Content Delivery Network. Our whole setup ran through a RackSpace Cloud Managed Service account. The CSS, the creepy BaconBaby maker Flash thing, lovely webfonts, javascripts and images all load from the RackSpace CDN. We also squeezed and optimized the hell out of the images to make them as small as possible. Side note: purging the CDN cache is *really* painful on RackSpace. Use version numbering (timestamps in the file names are a great option here (e.g., base_02-06-2012.css) in your file names, so you can make sure the end client gets the latest version of your file(s). You can purge via the CloudFiles API, but it can *still* take up to four hours for a purge to propagate through their network. Blargh. Also, the default TTL (Time to Live) for a CloudFiles container is 72 hours. We dropped the TTL for our main assets container down to an hour for the launch.

Step 3: Github for version control. We pushed and pulled from our private repository on Github. We used Deploy Keys in order to push code updates to staging boxes and eventually to production servers. (Though personally, I’m a huge fan of “Let’s do it live!” but thankfully, no one listens to me on that score. :-] )

Step 3: QA Test. Use Apache Benchmark (or Siege) to beat the crap out of the thing as much as possible. We used nginx as a web server because it’s incredibly light and fast. And since we are using “cloud” servers, we (well, the client) gets charged based on CPU usage, storage and bandwidth. Using nginx instead of apache also helps keep that cost down.

Step 4: Spread the load. We originally had two 4GB servers behind a dedicated Load Balancer. On Sunday morning, someone got a wee bit paranoid and/or panicky and spun up four more servers behind the load balancers. Honestly, with the leanness of the code and the CDN, I believe the site could have run on a just single server, but the overkill of servers was cheap, all things considered (~$100).

Step 5: Monitoring. We used Scout. Fun charts and notifications! Yay! The real time feature was fun to watch as well. I could tell when the west coast saw the ad, because the graphs spiked up, along with my pulse rate. Also, the Scout guys were incredibly responsive to support requests. The default nginx monitoring plug-in didn’t work with .htaccess password protection (so we could password protect the site while it was still in dev), and within an hour, they had not only responded with a workaround, but were offering to modifying the plug-in’s code to suit us. Nice.

Step 6: Guinness and mini bagel pizza bites are not acceptable food choices when you haven’t eaten all day because of all the freaking out.

(Yes, we put “Marry Bacon” ASCII art in the HTML source. :-] )