BP's Weblog

Well, Brad Choate explained how to do it for LightTPD, but for those of us with boring old LAMP installs, here's a brief howto for getting MT 3.2 working in FastCGI mode:

• First, make sure you've got FastCGI support in apache. On my Debian machine, that's the libapache-mod-fastcgi package, or libapache2-mod-fastcgi for apache2 (make sure you have non-free in your packages list).
• Likewise, you'll want CGI::Fast for Perl... get it via CPAN, or, again, the Debian package is libcgi-fast-perl
• Then, you'll need to add the support for mod-fastcgi to whatever directory you run MT from. I added it explicitly, but it appears that the Debian FastCGI package takes care of this already. Of course, you'll also need Options +ExecCGI for that directory, but, you've already done that, 'cause you've got a working MT install, right? If you want to add it explicitly, use "AddHandler fastcgi-script .fcgi", either in your .htaccess, or in the appropriate slot in your httpd.conf

• Now, modify Brad's example code a little. In particular, I had to add a line before the section of “use” lines

  use lib "lib";
  

  (this puts the mt/lib dir into the Perl library path) and a couple of lines that you'll have to edit to match your config: (I put these after the “use” lines, but I doubt that's necessary)

$ENV{"PERL5LIB"} = "/path/to/mt/lib";
$ENV{"MTHOME"} = "/path/to/mt";
$ENV{"MTCONFIG"} = "/path/to/mt/mt.cfg";

Name all of that mt.fcgi, in the same directory as your mt.cgi is now. I made hardlinks to the other names:

ln mt.fcgi mt-comments.fcgi  
ln mt.fcgi mt-tb.fcgi
ln mt.fcgi mt-search.fcgi
ln mt.fcgi mt-view.fcgi  
ln mt.fcgi mt-atom.fcgi

Then, I just use mt.fcgi instead of mt.cgi in my web requests. Nice!

So far, I haven't quite figured out how to get everything using the .fcgi interface... perhaps it's a problem with the PHP dynamic templates, but, after rebuilding my main page, all of the links that would've used .cgi now point to .fcgi. However, all of my single-entry archive pages still point to .cgi.

Anyway, there ya' go. Having problems? Comment below, maybe I can help.

UPDATE:

How to fix all things to use the .fcgi's is explained by Brad in the comments. Also, for those of us with weak LAMP installs, and low-traffic sites, some tuning suggestions: Add something like the following to your Apache configs to lower the default limits (file is /etc/apache/conf.d/fastcgi.conf on Debian)

FastCGIConfig -autoUpdate -idle-timeout 120 -killInterval 3600 -maxClassProcesses 3 -maxProcesses 15

You need to raise the idle timeout unless you have a super-quick machine. I was using the 125 row view for comments and trackbacks to clear out old ones, and it was regularly timing out - taking more than the default 30 seconds to rebuild. This can, probably, lead to bad behavior, if not just on-screen error messages.

Raise the kill interval to reduce the regularity of killing the processes. Why pay the overhead of restarting fastcgi processes on a low-volume site? You'd think you'd be able to specify a kill interval in terms of jobs served, but it's time based for whatever reason.

The last two numbers specify how many copies of a given script are kept around, and the total site-wide. It was silly to have 10 copies of mt.fcgi loaded since I'm the only one who uses the admin interface, but why would I want to have 10 copies of the comment script hanging around, either? The virtual memory impact of running all those MT processes was getting too large.

I'm sure there's some way to use the same trick that Brad outlines for LightTPD to use a single instance to handle all the requests. Probably some combination of SetHandler and some other Apache directives. I'll post an update if I figure it out, or anyone tells me...

Tags: mt32, fastcgi