This will be a short post. Mostly for people who are already using MT-Dispatch to serve Movable Type with FastCGI and background tasks.
I’ve released MT-Dispatch 1.4.
I will write the documentation later this week, and it will appear on this page.
What is new in this version?
- Movable Type 4.0 migration. (I’ll release 1.3 sometime later to backport my new features to MT 3.)
- Auto loading of MT App scripts.
- A plugin interface—recycle the dispatcher from the MT dashboard.
- Support for url rewrites, which is important for getting MT-Dispatch to work with Apache.
Testing
Hey Reed,
Do you think this plugin will help improve the comment performance on my blog? Right now there’s a delay of about 1 minute between a user submitting a comment and the page showing any signs that it has responded to the user’s actions. This is incredibly frustrating and also results in many duplicate comments as users keep clicking the submit button because the site appears un-responsive.
I have no idea how to solve this issue and thought maybe this plugin might help. Thanks.
Tim
Yeah, running you blog under FastCGI with background tasks speeds up commenting.
I also found that a good way to speed up commenting is to disable the SpamLookup-Lookups plugin. That plugin has to contact external servers for every comment posted, which can delay comment processing. I use TCode and CCode which make that plugin unnecessary.
Hi Reed,
I was just wondering what severity of memory problems you were seeing before writing this? Running MT4 under vanilla fcgid (and apache2) I’m seeing it eat an additional 1.5MB for every request to mt.cgi. Given my system limitations that means that, realistically, I couldn’t let any one process handle more than about 10 requests before reaping and restarting.
Is that even close to what you were seeing, and would you expect mt-dispatch to alleviate that at all - beyond the obvious benefit that it allows reaping of the processes _at all_?
Cheers,
Will
Hi Will,
We solved our memory issues more by moving to Lighttpd than by switching to the dispatcher.
The 1.5MB leak still exists with this dispatcher. Hopefully, with SixApart paying more attention to my solution, they’ll track it down and fix it.
Under that situation, the only advantage that the dispatcher will do for you is to allow you to automatically harvest your FCGI workers. If you are very memory limited you may only want to run a single worker.
Update