Beyond all the talk about big-picture, tectonic vectors of social media that came out of last week’s BlogOn conference, there were a few intriguing technical highlights. Most interesting to me was Ben and Mena’s preview of some of the new features in MT 3.1 (Mena’s entry there doesn’t include details yet, but stay tuned).
MT is database-driven, but generates static HTML pages, on the theory that this method reduces overall server load. With high-traffic sites, this is undoubtedly true — build a page once and serve it a million times without having to make repeated database requests. But the penalty for this model is that rebuild times can be annoying, depending on factors like CPU speed and current load, and the number of index templates set to auto-update. I’ve seen page builds take anywhere from 3 to 60 seconds, depending on circumstances. This becomes a real problem when you have multiple popular MT installations on a single machine. If one user updates a page while people are commenting on other blogs at the same time, CPU contention can get hairy for a while (especially when the comment spam bots are hitting multiple blogs simultaneously). Not to mention the fact that simple comment posting really should be as immediate as it is on any discussion board (it’s one thing to force a rebuild on the site author, quite another to make your readers sit through it).
But wait, there’s a database sitting behind MT — what in the architecture forces this static build model? Nothing at all. As Mena demonstrated last Friday, in MT 3.1 you’ll be able to check a “Live build” checkbox, modify a couple of MT tags in your templates, and switch your site to live/dynamic page generation.
The “WordPress” exodus is basically about two things: 1) Philosophical licensing differences (i.e. open source religion) and 2) Live page generation. There goes half the argument for moving to WP.
The interesting twist is that MT has always been a perl-based engine, while the live updating is PHP-based. So MT 3.1 will support inline PHP — write your own, download modules, drop them in place…. this is going to open up the universe of 3rd party MT plugin development immensely. Many of us have been using inline PHP with MT for years, but now we’ll have actual MT tags that make PHP calls.
I’d love to see some metrics comparing the build models: total distributed CPU load for one static build plus a million static requests, vs. a million dynamic requests. Then see how that compares with just a thousand pages, or 10. Deciding just how much traffic best justifies one publishing method or the other should generate some interesting case studies.
