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.

Yes, I’m still alive, and yes I’m still blogging.

It’s been a bit quiet for the past few days because I’ve been sorting out some server issues. Basically, my host ran out of memory on Friday morning, and I’ve been getting it upgraded and trying to sort out some of the memory use and performance issues since then. It’s nothing particularly huge, but it’s taken all of my non-work/non-gaming time. All the software work is now done, but there’s a server migration still to happen, that’ll come up when my hosting company (the excellent RimuHosting can sort out some trouble they’re having with broken Intel BIOSs. But since that’s almost entirely managed by them, it shouldn’t take any more time out of my blogging.

While I was at it, I installed a couple of plugins for Movable Type 4, which should give quite a bit more flexibility in how you sign in while commenting. Not that anyone ever does.

One of the new features in Movable Type 4 is native user registration. What that means to you is that you don’t need to go and sign up for a TypeKey ID to be a registered commenter here any more. Of course, if you do have a TypeKey account, you can still use it (and it might come in handy at other SixApart sites you visit,) but you shouldn’t have to have one.

Obviously, I haven’t tried it out yet, so if it doesn’t work for me, leave a comment (anonymously) on this topic, and I’ll look at why it might be broken.

I’ve just upgraded the site to the new, improved version of Movable Type (the blogging platform I use.) This should make improve the blog in the long run, but in the short term it basically just means that I’m back to using one of the default layouts. This will (maybe) change over time.
The only important thing that’s missing is the links to the feeds from the main page; the two afeeds (Atom and RSS) are both still there and working, but you can’t get to them unless you know they’re there.