The Movable Type and Professional Network Wiki has been moved to wiki.movabletype.org.
Movable Type Performance Tuning
byrne.vox.com at 2006-11-17 17:29:49.
Original Author: JayAllen
This is a growing list of do's and don't's with regards to performance tuning your Movable Type or Movable Type Enterprise installation. Please feel free to add your own.
If you are new to the subject, you may want to start off by reading the foundation article "How to Speed Up Publishing in Movable Type".
Use FastCGI or mod_perl
Using a persistent environment like FastCGI or mod_perl is crucial for eliminating the overhead associated with the startup and shutdown of perl CGI processes. This is Six Apart's highest recommendation and instructions can be found in the Installation Guide (although they are insufficient and in the process of being improved) and on the wiki page HostingMTUnderFastCGI. If you have the choice between the two, FastCGI is strongly encouraged because it is easier to set up, more actively developed and tested.
Run the latest version of Movable Type
Every version of Movable Type contains performance enhancements, some of which are extremely significant. This is especially true of Movable Type 3.2, Movable Type 3.3x and Movable Type Enterprise. if you are using an older version of Movable Type than the latest public release, you should absolutely upgrade in order to take advantage of these gains.
Using a SQL database
As Movable Type is a database driven application, your database performance is a major contributor to application performance. In most environments, the order of database performance from best to worst is listed below:
- Oracle 10g (MT Enterprise only)
- MySQL
- postgreSQL
- SQLite (Movable Type only)
- BerkeleyDB (Movable Type only)
Realize that this is a generalization and each database can be configured in ways that increase or decrease its performance with respect to its neighbors. If you are using one of the lower rated databases, you might want to consider a switch.
Eliminate unused or redundant archive maps
Although the ability to use multiple archive maps to output different representations of the same data is a big strength of Movable Type, it can also be one of the biggest drains on performance. Each archive map you create multiplies the work necessary to complete a rebuild.
For example, if you have only one category archive map and 30 categories, Movable Type will publish 30 distinct files. If you have two, it will publish 60 distinct files. Etc etc. Although caching helps a great deal, Movable Type cannot cache everything since each archive map can call for completely different set of entries or blog data.
If you are using multiple archive maps or have archive maps enabled that are not being used, you may want to very seriously reconsider. For example, if, in addition to a category archive map you also are publishing three different flavors of category feeds, you might want to reconsider publishing a single PHP data file of your category data and compile the different flavors upon request.
Reconsider your archives
Related to the previous point, while offering sixty different views of your blog data by category, date, individually and in different representations (HTML, PDF, RSS, RSS 2.0, Atom) might be cool, it's also ridiculously wasteful. Individual archives are important for permalinks and comments, but beyond that, how many different slices of your data do you really need?
In general, it's a good idea to consider focusing your publishing efforts on a particular type of browsing and let your indexed, feed subscriptions and search do the rest.
Reconsider redundant feeds
This may be a stretch for some, but how many different feeds do you need? Do you really need to support RSS 0.9, RSS 1.0 and RSS 2.0 - not to mention Atom? Just pick one of them and go with it. If you MUST support all formats, consider using FeedBurner. -- ByrneReese
Avoid wasteful rebuilds of index templates
If an index template does not contain Movable Type template tags (e.g. CSS file) or contains tags whose output does not change (e.g. RSD or Dynamic site bootstrapper), it does not need to be rebuilt automatically by the system. To turn off automatic rebuilding by these templates, navigate to the template's editing screen and uncheck "Rebuild this template automatically when rebuilding index templates".
If you have index templates you do not use (like test templates or the master archive index template), you should disable automatic rebuilding for them as well.
Use MTInclude file="" or MTInclude module=""
If you'd like to avoid the use of PHP includes or server-side includes for whatever reasons for including the same content on multiple pages, you may consider the MTInclude tag. The tag can be used in two different ways, each with their own pros and cons:
<$MTInclude module="MODULE_NAME"$><$MTInclude file="FILENAME"$>
The first parses the template code found in the module and then on each inclusion, evaluates it to produce your final output which is then included in the place of the tag. The second is the Movable Type equivalent of a PHP or SSI include in which the contents of the file are included in place of the template tag.
Movable Type template tags are evaluated in context on each invocation of MTInclude module and, under dynamic publishing, MTInclude module. Template tags are not parsed at all when using MTInclude file under static publishing.
Using one of these two invocations of the MTInclude tag can help a great deal in abstracting repeated content from your templates if you do not have PHP or SSIs enabled or if you want to have Movable Type perform all of the compilation and publishing work.
Avoid inefficient template code
Even if you have your archive maps perfectly configured to output only the archives you really need, the content of your template may cause Movable Type to do a lot of unnecessary work. The most common example of this occurs in the overloading of the sidebar of archive templates with iterative container tags like MTArchiveList and MTCategories/MTSubcategories. Anytime you use an iterative container tag in an archive template to print out the same content for each template, you are asking the system to duplicate it's work over and over again.
To greatly improve your publishing performance, you should consider having Movable Type compile and publish this information once and then include it into your template or final page. The ways to accomplish this are though use of:
- An index template which can be included into your page via PHP, SSI or
MTInclude file="" - A template module which, in MT 3.3x and MT Enterprise, affords far better caching than in previous versions.
If you have sidebar elements which change with every template and hence cannot be abstracted in this manner, you should seriously consider the value they provide to your customers versus their cost to you, your authors or your readers (if using dynamic publishing).
Avoid performance-killing plugins
Movable Type treats plugins as part of its own code. Each time you add a plugin, you add some modicum of performance overhead to your system. Well-coded plugins put a premium on performance by loading themselves only when needed, caching data (like the MT app does) and eschewing redundant or expensive processing.
Unfortunately, there are a number of plugins whose authors did not anticipate problems that may occur under heavy use or who simply took shortcuts in their creation. They are listed below:
- MT-Paginate - This plugin requires that you load up all of your entries for each template that you include its tags on. This is a massive red-flag and its use should be avoided at all costs.
- Rate-It - This plugin creates a row in plugindata for every single IP/entry pair initiated by the act of rating.
- Others?
It should be noted that the list above is and can never be comprehensive. If you are having performance problems, it pays to do some performance testing on each of your plugins. This can be done quantitatively using Perl's Bechmark modules or qualitatively by disabling the plugin and testing your rebuilds. The RebuildLess plugin (described below) also provides for logging of rebuild performance profiling data which may also be useful.
Use Dynamic Publishing (low traffic)
Dynamic publishing removes the load of compilation and publishing of Movable Type data and spreads it out in much smaller incrememtns across each request by your readers. Dynamic publishing is excellent for small installations without a massive readership especiallly when used in conjunction with MT's native dynamic page caching and conditional request features. You can read more about the benefits of dynamic publishing here.
Of course, because at least a database connection and at most a page compilation is required for each page request, the attractiveness of dynamic publishing decreases with an inverse proportionality to your page views.
Avoid overuse of categories
Before Movable Type had tags, many people used categories in their place, creating, in some cases, thousands of categories. The effect that this has on the Movable Type publishing system and the administrative interface is disastrous. Not only is every MTEntries loop slower but if you have category archives enabled (and why wouldn't you?), the system must publish a single file for every category you create containing all of the entries in that category. In addition, category listings both in the administrative interface and on your archive sidebars, become simply unusable.
If you are using categories in this way, you should absolutely stop and migrate your categories to tags, which ahve been designed to scale to thousands of items.
Use Mullet category archives
Currently, Movable Type's default category archive template prints out nearly all entry information for each entry in each category. As your number of categories and entries increase, the work required to complete this publishing increases at an amazingly fast rate, especially if entries are assigned multiple categories.
To greatly improve your publishing performance using category archives, you may want to consider switching to "mullet archives". Mullet archives are so named not because they are ugly and unfashionable but because they are asymmetrical in the data they output. In a typical mullet archive, you might see:
- Full entries for the most recent five entries
- Titles and excerpts for the next ten entries
- Only linked titles for the rest of the entries
In addition, you may want to consider limiting your category archives to a certain number of entries and let search, tags or the master archive index (see below) take care of those who are looking for further information.
In doing this, your category archives become more like category-specific main indexes. And your MT install will be much happier.
Use the master archive index
The master archive index is essentially the site map to your blog's entries. The default master archive index is certainly nothing pretty to look at but it has one a massive benefit: It's published ONLY ONCE. Compare that to the exponential publishing of archive templates with redundant data and it's easy to see how this template may be quite useful.
Instead of publishing category archives or monthly archives, you might want to consider publishing all of your linked entry titles out once and grouping them by date or category. This can be made rather nice using some Javascript to filter the listing and could even pull data as requested using Ajax.
Disabling the "placement cache"
If you have a large number category assignments and are having issue with your server's memory usage, you may want to consider disabling your placement cache.
Use Plugins to Optimize Rebuilds
MT-Burn plugin
To be completed
RebuildQueue plugin
To be completed
RebuildLess plugin
To be completed
byrne.vox.com at 2006-11-17 17:29:49.
