Thinkcorps

I am part of SMITH, an online magazine of personal stories, and we’ve been working on a serialized graphic novel based on reporter Anthony Lappé’s experiences in Iraq called Shooting War. Well, we had the good fortune to have BoingBoing link to us late today. Thank you Mark and the BoingBoingers!

Anyway, the server started having a fit almost immediately. I logged in and top had the server load at around 25 (highest I saw was 78), which is bad. I had already turned on the Wordpress Staticize caching plugin. (Oh Mommy.)

I quickly worked to resize the comic’s images, compressing them about 50% further. Then I realized I should offload all images entirely. So I signed up with Photobucket (thank you Web 2.0), and uploaded all the images to them, and rewrote the chapter pages, with the new image urls. Luckily, I already wrote a script to create the code for each chapter, so I only had to make a few tweaks, and then paste up the new code.

This seemed to placate the universe, as the load went down to about 15. The problem seemed to be MySQL (I’m guessing). Since Wordpress relies on MySQL for storage, I needed to see if there was a way to export a static html version of your site. I guess I was trying to get back to how Movable Type used to publish out html. I went looking for a plugin and damned if I didn’t find a better solution.

Elliot Beck wrote a plugin called Digg Defender. It rewrites requests that come with a referrer from the big sites (Slashdot, BoingBoing, Digg), and redirects them to the Coral Cache. What’s the Coral Cache? Yeah, I didn’t know either.
I tweaked the plugin to rewrite everything, since the BoingBoing link only went to the homepage, and everyone was clicking through 15-page chapters. (One things calm down, I’ll change it back to only rewrite certain referrers.)

So, within about two hours, and with almost no idea of what I would do, I’ve now got our site completely cached through free services on the Net. I love the Internet.

[Note: Each comic chapter was set up as a number of ‘pages’, using the ‘nextpage’ tag in Wordpress. I wonder if that adversely affected caching performance? I’m not sure, but may investigate later.]

UPDATE: I thought for a moment this morning that I’d spoken too soon. But I did what I had to do. Coral Cache is not perfect and we had an update to the site (a new chapter) to publish this morning, which took a few hours to show up properly. And there was a separate problem that required a MySQL restart.

After freaking out, and having friends calm me down (thank you Ted and Alex), I realized that I’d done the most important thing, keep the server up. There’s really nothing else to do when you get Boing’d or /.-ed, except wait it out.

Moving to a dedicated server would have taken a week at which point the Boing effect would be gone, and our server’s already pretty good and almost dedicated. Publishing a new chapter wasn’t a mistake really, but trying to do that while a cache is in effect is going to be messy.

Extra Tips for Digg Defender: Make sure you add lines in the digg-defender-phase-1.php file (to the if statement) so that you’re not rewriting any admin pages, or the login page, or maybe the comments-post page. Mine looks like this now:

if(
!strpos($_SERVER['REQUEST_URI'],'wp-comments-post.php') &&
!strpos($_SERVER['REQUEST_URI'],'/wp-login.php') &&
!strpos($_SERVER['REQUEST_URI'],'/wp-admin/') &&
strpos($_SERVER['HTTP_USER_AGENT'], 'Coral') === false ) {
$url = digg_defender_coralify('http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
header("Location: $url");
die();
}