MT Performance Tips
Six Apart has published tips for improving the speed of MT page rebuilds. Other then the dynamic pages push, they are fine and have been somewhat helpful to me in the past, but I've found others to be much more valuable.
Before I share those let me clarify why I mention the dynamic pages push as not being fine.
I have been critical of MT's dynamic page feature from the start and still remain completely unconvinced about them. While static pages takes a bit more effort to implement correctly, they will always out perform dynamic pages. Performance is not the only reason though. Your options are limited in terms of what database you can use. The majority of plugins for MT are written in Perl and only can be used in static mode. (The dynamic page technology in MT is implemented in PHP, entirely different scripting language.) There are also other little nagging differences that Six Apart warns of.
This post is not about my issues with dynamic publishing though. I'll just say I don't use them and probably won't any time soon.
Over on the ProNet mailing list Bruce Prochnau was trying to port a MT weblog over to dynamic page generation to reduce the amount of time it takes to rebuild a site. Initially he was reporting a complete rebuild of a 2000+ entry site was taking about 1 hour to complete at one time. Recently switching hosts to a more powerful box cut the rebuild times down to 27 minutes.
During the course of the conversation that followed, Jake Ortman suggested Bruce move some markup to separate index templates and then insert that content into the template with a bit of PHP code. Rebuilds are now down to 3 minutes. Quite a gain in performance.
It's worth noting that this type of scenario is not just limited to includes though. Any repetitive lookup of the same data through out your templates will cause substantial slowdowns.
I've helped a number of people complaining about MT's poor performance and have seen similar gains with just a few tweaks to their templates. The biggest culprit in my experience was the inclusion of the Recent Entries linked list in the sidebar. Each time a page was rendered MT was hitting the database for a list of the latest entries that had been published. Some unfortunate souls took this one a step further by adding a recently comments or recently commented entries list also adding to the drain. Publishing this information once and using an include will avoid this situation and improve performance a great deal. If you are indifferent to it in your templates you can take it out and avoid the need for SSI or PHP.
Couple of other drains are calendars and next/previous navigation.
Calendars are surprisingly really processor intensive things to calculate and layout. MT does some to alleviate the drain, but it still puts a hit on performance. I suggest not using them unless you really must have them. If you do, then some SSI/PHP, file naming and archive template tricks will help marginalize their impact. How these are applied depend on how you are using calendars in your weblog.
I haven't experimented with general archive lists in the sidebar, I would guess that having an extensive list of linked archives could contribute to a lag in page build performance also. That is just a guess though.
Previous and next navigation also will cause your system to drag because MT does an individual database query for each one it happens upon. That query is a rather complex one that I presume take a fair amount of resources to determine. (God help you if you are using BerkeleyDB as your database to perform this query over and over again. You need to move to SQLite anyway.) This adds a substantial amount of extra database activity. The support of previous/next navigation also has some side effects in rebuilding, but those are out of our hands since it would require some code hacking to address.
Incidentally all of these performance zapping no-no's are featured in the default template sets re-enforcing the perception that MT is really slow and a resource hog to the masses.
I've found that the performance of MT page generation can be quite good with some smart choices. Unfortunately making those smart choices aren't so apparent without tracing through the code to determine were the gotchas are. Hopefully posts like these will help though.
