dooce® Community: Some Info for the Nerds

Some of you will likely be asking why did we launch a community website? For the answer to that question, you can read this post on For those of you wondering how we built it, I’m not going to go into too much depth, but I’ll share a few things below that might pre-emptively answer a few questions.

What/who did you use to build the new community site?
An army of super robots! No. We partnered with XOXCO to do the development work. On the way to launch, the always affable and sharp Ben Durbin helped us migrate the database(s) to their own server and gave us some good advice on a few things to look into on the back end to help handle the traffic.

We use Drupal and a whole lot of custom code from Ben at XOXCO. He’s developed a cool framework called PeoplePods but because we like our Drupal (more about why later), he kindly agreed to bend to our Drupal overlords. Any time we mention Drupal, we should probably mention the crew at Lullabot, because they are awesome Drupal people and have great insight about using Drupal on every level.

Why did you use Drupal?
Because it has served extremely well, including the time Heather gave away some stuff and that post got over 40,000 comments. In a day and a half. To let you know just how robust Drupal as a framework is, the web serving software Apache died before Drupal did.

Drupal supports memcached (wikipedia entry here), a really sweet memory caching system that makes serving dynamic content less resource intensive. Drupal also has it’s own level of caching that helps servers keep up with traffic and the two together are amazing, especially in regards to serving dynamic content to a number of people.

Why didn’t you develop this in-house
I know just enough about Drupal to be dangerous. I can hack around a bit, but as for doing the work that XOXCO did, I’d still be getting the homepage template to display. We had a relatively short development time (Marlo was born before we really rolled up our sleeves) and needed somebody who had experience not just coding and developing communities, but also could advise us on managing a community after launch. The insights have proven invaluable and have enabled us to launch an experience that matches the quality and fun people expect from

Did you bump up your server horsepower?
Oh hell yes! You should be noticing a much faster experience on and that should be the case with the community site. Total pageload might not be increased for you, but as far as the content goes (sometimes ad servers can be slow), the page should load much faster than before. We have put the webservers behind a load balancer. We moved the database to its own box. Our testing environment is a separate box away from everything. In short, our hosting bill just exploded. However, for you, the kindly reader, it should mean no down time (never say never), especially during things like server upgrades, software upgrades and traffic spikes. Plus, we’ll have a little insurance should catastrophe strike. Liquidweb was a big help in setting us up to handle this launch. Without the two Bens and the ever awesome Mike N., I’d still be on the phone trying to figure out the best way to go about this. We did load testing of all the new stuff and it’s really cool to watch the load balancer divvy up the traffic.

Why the hell didn’t you load balance your shit years ago, doofus?
It’s expensive. And frankly, we never really needed to. However, with a community site, the dynamics of things change dramatically. only sees a lot of database activity when comments are turned on. Even then, it’s relatively minor. By turning on user registration, that decreases the amount of caching that Drupal will do and that means more database access.

Any other questions? Hit me in the comments below and I hope you enjoy playing around on the new site.