Problems with Movable Type

Posted .

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.

5 Responses to “Problems with Movable Type”

  1. Robert McGovern

    You went with WP then, I wondered as suddenly I got lots of unread stories. One nice thing, for me, of the change is that you have properly formatted text in your RSS feed now. Previously, with MT4 I think, the links where simply shown as text which made some posts horrible to read.

  2. Will

    Yeah – I installed it in parallel to see how it worked out, and it won me over pretty quickly. There are things it doesn’t do as well as MT, but overall it’s a better package. Especially for an amateur single blogger, who’s technically competent, like me.

    I hadn’t noticed the bad formatting on the MT RSS feed until I went to check that WP’s matched it. I’d have done something about it sooner, otherwise.

    Out of interest, how many repeated entries did you get?

  3. Robert McGovern

    10 where reposted, not to many really. One recommendation with using WP is to make sure you have spam filters / authentication of some sort set up for the comments.

    The last time I ran a WP blog I was getting spamed to heck!

  4. Will

    Oh right, yeah. 10 is the number that the RSS feed makes available; I’d expect those to be duplicated, since WP and MT will have assigned different IDs to the posts.

    Spam filters are provided out of the box in WP these days – so I’m hoping the default set will work and not require me to enforce user authentication; that just puts people off commenting, which I don’t want to do. So far it seems OK – I used to get a lot of confirmation requests from MT, because it wasn’t sure if a comment was spam or not (about 10 a day, plus the comments it was sure were spam,) since moving to WP, I’ve seen no spam comments go up, and haven’t been asked about any either. So, either the spambots haven’t figured out that I’m using WP yet, or it’s already doing a better job of filtering than MT used to.