Migrating from WordPress to Movable Type

Okay, I know I’m cutting against the grain here but I’m going to migrate back to Movable Type after dabbling with WordPress for a few months. Yes, the installation of WordPress is easier. Yes it’s nice not to have to rebuild pages all the time. The WordPress skins are good but I don’t really have an overwhelming urge to change the look-and-feel of my site every week (heh – or every 5 years).

So why I am returning to Movable Type? The principle reason is entry, comment, and category management. I find these tasks to be incredibly tedious with WordPress. That doesn’t mean that the interface isn’t showing promise. WordPress has some very attractive and innovative features.

Still, I find Movable Type to be far simpler in terms of editing, layout, includes, etc. I vastly prefer the module include system of Movable Type over the php includes of WordPress. And as a Perl programmer familiar with the Template Toolkit System, Movable Types templating system makes much more intuitive sense to me than the egregious PHP functions of WordPress. Personally, I hate PHP. It’s just pure nastiness.

And I have to admit that I find touches like the “Howdy, [user]” to just be needlessly tacky and unprofessional. It’s like inserting expletives in preliminary draft of a manuscript and then forgetting to remove them.

The rebuilding of pages and includes can become incredibly irritating with Movable Type. To minimize this, I do all of my prototyping offline and build a single static design. From there, I can easily break it out into modules and templates as necessary.

Bio::WormBase.pm released to SourceForge

I’ve made a huge number of changes under the hood to make the update process simpler and more stable. A number of things precipitated these changes, including the rapidly expanding size of the database, increasing number of denormalized support databases, the need to run the site in a load balancing situation — and most importantly, the looming addition of 3 new species sometime this year.

I’ve refactored the old Bio::GMOD modules into its own namespace — Bio::WormBase — in part to avoid possible future namespace conflicts as well as too allow a degree of flexibility not present in the old modules.

– Resumable downloads (no longer limited to the Net::FTP/Perl 2GB limit of some architectures).
– purging of old releases
– versioning of all mysql databases, etc, etc, etc
– consolidation and versioning of blast, blat, and epcr databases

To do:
– Service monitoring and restarting as necessary (underway)

You can check out these new modules from sourceforge. I would encourage all of you to become sourceforge developers if you aren’t already so that we can work together to make the mirroring process as streamlined as possible. Please contact me so that I can add you to the list of developers. The project name is bio-wormbase, and the first module is Bio-WormBase.pm. I plan on adding a bunch of other things, such as data mining examples, adminstrative scripts, etc.


Thanks for all your help!


The following documentation is copy-pasted from our Wiki where it is a little easier to read


Fetching the new modules:
Anonymous access:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bio-wormbase login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bio-wormbase co -P Bio-WormBase.pm

Developer access:
export CVS_RSH=ssh
cvs -z3 -d:ext:developername@cvs.sourceforge.net:/cvsroot/bio-wormbase co -P Bio-WormBase.pm

performance tuning httpd

Today I’m working on performance tuning httpd on the primary production server. It has totally been out of hand this week.

1. Increase MinSpareServers and MaxSpareServers.

MinSpareServers 10
MaxSpareServers 20
StartServers 20

This should decrease the amount of time that apache must spend spawning new processes to handle requests.

2. Set the MaxRequestsPerChild to a high value.

I set this (back) to the default of 10000. I think our initial setting was too low causing httpd to continously spawn new processes.

3. Disable server-status

This just causes apache to keep track of lots of things that it doesn’t need to track.

4. Use Apache::SizeLimit to kill off processes if they grow too large.