Pardon the dust around here recently. Have been growing increasingly frustrated with the time it took to post a new entry — as long as 80 seconds, and around 60 for guests to leave a new comment. The latter was becoming a genuine problem because people would get impatient and hit the Post button repeatedly, so I’d end up with duplicate or triplicate comments.
This isn’t the fastest CGI server in the world (trying to garner enough customers to warrant an upgrade), but I knew something wasn’t right. Post time had been increasing with the size of the database, which didn’t make sense since as a well-designed web app doesn’t care about the size of the database; the millionth entry should post as quickly as the first, pert near. Movable Type is exceptionally well designed, so I couldn’t believe it would contain a design flaw this glaring, and yet it was true; slower by the day, with just over a thousand entries. Other blogs with fewer entries on the very same server take only seconds to generate new entries. MT entry URLs are padded to ten million posts; one has to wonder what the post time would be like after a decade of blogging, even on a superfast server. Decided to get to the root of the problem.
I had read various theories about this in the MT forums. The most common suggestion is to not use MT Modules and includes. Instead, generate include files via Index Templates, then suck the output into your pages via PHP, SSI, or whatever you like. By putting re-usable content into index templates, custom MT tags still get properly parsed, but MT won’t need to generate the same data for every page each time the database is modified. Instead MT will crunch the include file once, and the http daemon will include it in the page at request time. I replaced all of my MT includes with PHP includes. Result: almost nothing. Post and comment time was virtually unchanged. MT modules were not at fault.
Next I tried removing everything fancy and stripping the templates down to “factory install.” No significant change.
A few times in the past, I’ve modified the timestamp of entries, which resulted in their numerical order not matching their chronological order. I’ve often wondered if this fact was causing MT to do more work. The only way I could think of to test this cleanly was to export all entries, create a new test blog, import all entries (thus re-assigning the post IDs to each entry), and testing post and comment time again. Some success! The “virgin” blog took “only” 62 seconds to generate a new post, and 40 seconds to leave a comment. Better, but still unacceptable. If I were to write a blogging system myself with PHP, post and comment time would be virtually nil, even if generating static pages like MT does. I was looking for something closer to five seconds.
Thinking about what one user had said about the <MTEntryArchive> tag being slow, I went into the Archiving section of the config and disabled Monthly and Category archives. Unfortunately, I now got a build error with my Archives include, since MT is no longer maintaining these archive types. So I made the Monthly and Category archive lists into static PHP includes and tried again. Whoa! Post time decreased to 18 seconds and comment time to 15 seconds. Not quite what I was after, but it was at least within the realm of the acceptable.
However, this means that new posts are no longer added to the Monthly or Category pages automatically. My first thought was to use the MTRebuild plugin to rebuild those archives once a night via cron, but of course that won’t work since I’ve disabled archiving for those two types. They can’t be rebuilt if MT isn’t aware of them. That means I’ll have to rebuild them manually from time to time by turning archiving on for those two, rebuilding, and turning it off again.
So. I’ve achieved a significant speedup (leaving comments should be less frustrating now) but at the expense of some of the cooler automated features. I still consider this a big flaw in MT’s design, and hope it will be worked out in MT Pro.