About a month ago, I upgraded the blog to run on the new release of Movable Type: 4.0. It has a nicer interface, plenty of neat features out of the box (without having to manage a host of plugins) and features some handy improvements to the template language it uses to build pages. It delivers on everything it promised, and in all, I’d call it a good upgrade over the venerable version 3, which I had been using. Of course this is technology and there are no absolutes, and MT4 has some serious gotchas, which I’m having a varying degree of success working around.

The first thing I noticed when I upgraded was all those improvements to the template language made my existing templates obsolete. This one’s not a deal-breaker; I just picked my favourite stock theme and ran with it; I can change it later. In fact, you could call this a win, since my existing templates were a mess, and had been hacked together before I really knew what I was doing; this is a chance to make a clean start – isn’t that what every developer always wants?

Slightly more seriously many of the well known and popular community plugins don’t work with MT4 - they’ve changed the way certain things work, and that means trouble for any plugin that relied on things happening the old way. The big loss is the blogroll plugin. There’s an upgrade to the plugin on the way, and I can live without it for a while, I just wish I didn’t have to. Actually, I’m not sure why SixApart haven’t rolled that particular plugin into the main distribution yet. Many of the new features present in MT4 are actually just plugins that have been made part of the default distribution, so why not something so widely used as the blogroll plugin? Beats me.

Of course, if all of the problems were little issues like that, which will go away with a bit of time and/or effort, I wouldn’t even be writing this. There’s a great big chunking problem that is actually starting to make me regret going with MT: performance.

MT4 is slow, and when I say slow, I mean really slow. It pre-generates the site (the much maligned re-building step you’ll hear the Wordpress users going on about,) so the user facing side of the site remains nice and quick, but the administrative interface feels like it’s running on a ZX-81. When I first installed the MT4 upgrade, the dashboard took about 6 seconds to load, compared to well under a second for any of the generated pages, so I know it’s the MT backend cgi scripts that are at fault, rather than my webserver or the network infrastructure between here and my host. Installing memcached and moving my virtual server to a much faster machine have made a noticeable difference, but it’s still taking 3-4 seconds to load any of the administrative pages, and when you’ve got a few things to do that gets really annoying, really quickly.

Enter FastCGI. This is an apache extension that keeps the perl runtime and compiled perl code of cgi scripts in memory, drastically reducing the start-up time of those scripts. Creating and starting a new process is a relatively time consuming operation, and compiling the perl code takes time too, so taking those two actions out of the startup of a cgi script can have a dramatic effect on the time taken to serve requests. I’ve trialled this, and it makes a huge difference: combined with memcached to cache the database connection, it makes the admin pages run about as quickly as the static pages. That’s impressive, but it comes with a cost.

Because FastCGI keeps CGI scripts in memory between runs, any memory that they allocate stays allocated too. That’s not a problem in the normal case, but it means that if your CGI script has a memory leak, that the leaked memory is lost for the duration of the FastCGI session (which is usually a couple of hours, at least,) and worse, is lost again every time the script is executed.

Predictably enough, MT4 has a memory leak. It seems to lose about a megabyte of memory every time it’s called under FastCGI, which isn’t a massive proportion of my server’s total memory, but it’s a lot to just lose while generating a web page to display, and it does add up. Unless it’s periodically freed, I’m going to run out of memory eventually – after about 1,000 administrative page views.

So, what can I do? There are three options, none of them ideal:

Live with the delay

It’s a real possibility. The user-facing side of the site runs fine, and I’m not going to actually die for want of a few seconds lost loading a web page. It doesn’t sit well with my geeky nature though, especially since playing around with FastCGI has proved that there’s no need for the pages to be so slow.

Fix MT

I’m sure I could – eventually – track down the memory leak and remove it, and possibly even get the fix put back into the mainline of MT. The question is how long it’s going to take and how much effort it will be. Also, if the fix doesn’t find it’s way back into SixApart’s code-base them I’m stuck having to hack every upgrade release in the same way, which sounds like a nightmare to me.

Dump MT

A bit extreme perhaps, but it would avoid the problem. Everything I’ve read suggests that Wordpress (the obvious other candidate) doesn’t have performance issues. I’m reluctant to take this step now (although if I was setting up from scratch, knowing what I know now, I’d use it over MT,) simply because I have a lot invested in MT; I know how to use it, I’ve got it configured, and it lets me edit my posts in MarkDown, which my googling has suggested doesn’t work so well in Wordpress. So I don’t want to change, but if I can’t fix MT, and I can’t live with the annoyance, it might yet come to it.