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.
Err… for fear of saying something incredibly obvious, but somewhere down the line I’m missing the just-in-time option: build dynamic, the first time a page is (re-)queried, then save to disk. Obviously this wouldn’t give you all the nice dynamic options, but it _would_ spread the building loads..
That can certainly be done with Zend/PHP, but whether MT will integrate that deeply with the external apache and PHP stuff it would take to do that, I don’t know. I’m guessing this will be left up to 3rd party developers, but we’ll see…
We’ll be explaining more on this soon, but the PHP integration in MT3.1 makes use of Smarty, so the caching of dynamic templates is pretty smart.
I noticed how everyone got in an uproar about the ‘new’ MT licensing but it’s not like they were closed off about it. They did, in fact, revise them to something more akin to what most people would want/were complaining about.
Of course, not many people that were bitching noticed because they already switched or didn’t bother to check.
Speaking of switching, “live” data (and a PHP foundation) were some reasons why I switched from MT to pMachine. Their new produce, ExpressionEngine, is even more powerful and flexible.
Anil – saw you at Webvisions, excellent presentation – I’d be curious how EE and MT caching compare.
Les, we (the J-School) were very grateful for the revised pricing – it’s what enabled us to keep using it at all (without the revisions it would have cost thousands of dollars to stay in the game). Now we’re fully licensed for good, as many blogs as we like, as long as the total of enrolled students stays at 100.
A. White, pMachine is an *excellent* system — I considered switching to it a year ago; only momentum, the support base, the plugin base etc. kept me on MT.
Here’s hoping for interest in journalism to stay flat!
:)
Just thought I’d quickly comment on the “open source religion” jab. While personally, I like people who try to make their behavior conform to their beliefs, I won’t make this a defense of zealotry, because I said it would be a quick comment.
The quick point is that one of the things the licensing snafu proved to users is that their rights to their MT blog is/was precarious. If and when the authors want to change the rules, they can and did. Blogs are, to many, a very personal thing, and so not surprisingly this scared some and really irked others.
Shifting to a free software blog solution, like I did with http://b2evolution.net guarantees me that I won’t have the rug pulled out from under me. I’ve got the code, and me and thousands of others who know some php can keep it chugging along no matter what the current lead developers do.
In fact, that’s how b2evolution started to begin with. The GPL’d blog engine b2 was abandoned by its original author and, because it was GPL’d, others were able to bring it back better than ever as b2evolution.
So, it’s not just “religion” that’s behind the MT exodus. It’s peace of mind. It’s freedom. It’s putting me in control. You don’t need open source religion to appreciate those things.
Hi Brian –
The “open source religion” comment was not meant as a jab – my point in using that phrase is that many people feel so strongly about all the points you make that their belief takes on a religious zealotry. And I share in much of this zealotry for open source solutions, which is why I came so close to migrating to WordPress myself.