As part of my Movable Type 4.1 upgrade project, I noticed that depending on my template settings, republishing the whole site would get extremely slow. Movable Type sometimes catches flak for this because it’s designed to serve static pages, so the "build" time tends to be a bit slower. (A good tradeoff in my opinion.)
There is much room for improvement on the rebuild times. It looks like the next release of Movable Type will focus on performance and scalability, so here’s my first contribution to that effort.
After some trial and error, I discovered that the Archives sidebar widget makes a big performance impact on rebuild. The Archives widget is designed to display links to different archive types available, depending on the page on which it’s being used. In my configuration, it will show the category and monthly archive links (with article counts) when shown on an individual entry page. (See screenshot at right.)
Because it’s showing information about other archive types, this widget needs to calculate that on the fly during a rebuild, resulting in lots of database lookups. What if it repeated that whole process for each page rather than computing it once and caching it?
To test the theory, I ran a series of test on my local MT installation running on my WinXP desktop. For MySQL, I enabled the general query log and did not turn on any caching. As such, the elapsed time numbers may not be that meaningful, but the relative performance should be.
I ran two performance tests — rebuild 10 entries, rebuild entire site — with the archives widget on and off. (The full site rebuild included 493 entries.) The results were as follows:
Rebuild 10 Entries
| No Archive Widget | Archive Widget | Delta | |
| Elapsed Time (mm:ss) | 1:30 | 3:23 | +125% |
| Total MySQL Queries | 3,243 | 6,014 | +85% |
Rebuild Entire Site
| No Archive Widget | Archive Widget | Delta | |
| Elapsed Time (mm:ss) | 8:10 | 41:20 | +400% |
| Total MySQL Queries | 18,104 | 101,257 | +460% |
The results are pretty interesting: even when rebuilding just 10 entries, you can see the effect the archives widget has on the numbers. When rebuilding the entire site, the number of SQL queries is over 5 times larger. I’m assuming that the number of queries is the main contributor to the build time. From this I’m concluding that the archives widget is a performance bottleneck during the rebuild process.
Next I’m going to try this same test with the special build of MT that includes performance logging to see if that provides any more insights.