It's rather disconcerting to see the elevator doors sweep open to reveal three unaccompanied freezers huddled together, leaving one human sized space by the control panel. Perhaps they decided to show initiative and move themselves over from the old building and only made it as far as the elevator? Or maybe their human handlers had something else to do and decided to keep them amused by running them up and down the elevator like little children?

Or maybe it's more sinister? Could this be the new trojan horse? Are three stooped over and disoriented invaders about to tumble out of their refrigerated shells?

Update 1/27/07: MT 3.34 is out with improved FastCGI support and between that and some experience, I've tweaked my setup some. I need to write up a better set of instructions, but right now my computer is in for repairs and I'm not up to writing a lengthy entry on a borrowed computer right now. The main things that I've changed are that I'm now having LightTPD spawn only one dispatch process and I've added one important line to the dispatch script as follows:

Just inside the eval block right above the line that reads: while (my $q = new CGI::Fast) { I've added in require MT; and right above the line that reads: $app->init_request(CGIObject => $q) unless $app->{init_request}; I've added the line: MT->set_instance($app);

These changes are to more closely match how the bootstrap module handles starting up a script and adding that line seems to allow comments to be reliably published through FastCGI.

However I am still getting periodic out of memory errors when I do more than a couple of big actions in a row such as a rebuild a comment and another rebuild. That makes me worry about what will happen as the blog grows.

Original text below:

Since it seems to be a bit of a moving target (and just so I remember myself), I thought I'd share what I did in order to get my Movable Type installation running with LightTPD and FastCGI at TextDrive. Needless to say, your milage may vary, especially at other hosts (and really I'm not sure that any other host will let you make this setup).

Why did I do this and was it worth it?

If you want to skip the background and get straight to the step by step instructions skip to the extended entry.

Unfortunately the real answer is probably a not so high minded "because I could" or "to see if I could" but in general if there's a better way to do things, I like to at least try to take advantage of it. To be certain, I'm seeking to solve a problem that I don't suffer from all that much. The problem being that standard CGI is slow. Every request for the CGI program will cause the perl (in this case) script to be compiled and loaded into memory even if you just used the same program a few seconds ago. This means that the user waits and the server gets the load of repeatedly starting new processes. It's easy to see how a stateless protocol like http would encourage this, but it can suck, especially when your blog gets hammered by spammers (or users for that matter) generating a huge number of requests to the comment or trackback script in quick succession. Even in normal operation, it simply slows things down and is one reason some people may find Movable Type less appealing than blogging applications which take a different approach, such as using php. The "standard" approach for fixing this in recent years has been to compile a script interpreter into Apache via a module like mod_php, but for a number of reasons that I don't entirely understand, mod_perl is not as secure or common as mod_php. FastCGI seeks to remedy this problem by starting one or more persistent processes which start up once and handle requests for scripts, staying active between requests. Unfortunately, Apache's implementation of FastCGI isn't very good (again for reasons that I do not entirely understand), however LightTPD was designed with good FastCGI support built in. Some people may favor using LightTPD anyway, even for serving static content because it apparently scales much better than Apache for handling high levels of traffic without requiring unreasonable amounts of resources.

So... Was it worth it? Well, as I said, I have neither a high traffic site nor one that has so far attracted (much) spamming, but the second at least is inevitable with time, and who knows, I could see more traffic someday. The bottom line, though, is that where I see the most difference is in the responsiveness of the application, and there you really can tell the difference. You click and the new page pops open. To be sure, there are still delays sometimes, and it isn't as if the rebuilds have gone away, but I never, anymore, have to wait for a link to open longer than I would expect from any static website.

Disadvantages? Well, anytime you stray out of the standard or increase the complexity of your setup, you do risk something unforeseen going wrong. You should probably keep a bit of a closer eye on things set up this way than you would otherwise. At first I did have a couple of major ongoing complaints with my setup: If you want to avoid having the port number in all of your links to the Movable Type application, you will need to proxy through from Apache to LightTPD which, in my hands anyway, causes Movable Type to see all incoming connections to be from localhost, confusing the spam filters. Also, the proxy setup means that you can't adjust mod_security yourself (you'd have to file a ticket to get them to disable it or modify the rules for you). Because of these problems, I've scrapped the proxy setup and simply have links to the application go directly to my LightTPD port. I'm waiting to hear from anyone about whether this could be a bad idea for some reason, but I'm happy so far.

Update 12/10/06: Thanks to a comment from Brad Choate, I've now fixed the problem with Movable Type seeing the wrong IP address and so I am now using the proxying method instead of pointing directly to the LightTPD port, and I've described that setup below.

Ok, here's the goods. Read on for the detailed version of how I got things set up:

Ok, yes, I know that's tautology, but usually spam at least has a chance of benefitting the spammer somehow. But why, oh why, did I get trackback spam pointing to, and only pointing to, google?

To whom it may concern:

You might wish to note that if--when I'm riding on the bus, and it's in the middle of a wind storm, and the driver is talking loudly to the driver of another bus that seems to be stuck, and I'm listening to music on my headphones--the music you are playing through your headphones is the loudest thing I can hear, then you are playing your music too loud and you probably don't have to look any further for the reason why you've gone deaf.

Wow! We had a serious windstorm here in Seattle last night. I've never felt anything quite like it. The closest thing was the windstorm they had in Chicago when I visited there four years ago. My apartment building was shaking in the gusts and I watched, more than a little horrified, as my big window in the living room bowed in and out.

I was lucky, though. I only lost power very briefly and nothing was damaged. Or at least nothing of mine was damaged. There are shingles strewn about outside the building, so I can't vouch for the roof. Many of my coworkers were still without power this morning.

I'm heading off to Boston in a few minutes to spend the holidays with Sasha!

As this is the first blog enabled Christmas, hopefully this year will bring many pictures and maybe even some video for friends and family over at Vox as well as here.

Sasha and I went to the beach today! We spent the morning wandering around Cambridge and wanted to wander around another neighborhood afterward, so she got the brilliant idea that we should take the blue line out to Revere Beach. It was very cool, both literally because it had just snowed--finally, it's been an unusually warm December--and because it was so pretty. Also, Sasha was adorable running around on the sand and snow.

I also put up a couple of movies of Sasha capering at the beach here and here. We also met a dog named Gohan.