One of the biggies about the Movable Type 3.34 upgrade was its built-in, out-of-the-box support for FastCGI, a remain-memory-resident implementation of the CGI used to run the MT scripts. Since loading up MT modules into memory takes time (esp. during spam attacks), this was intended to speed things up mightily.
We have been educating users for some time about the benefits of hosting Movable Type under FastCGI, a free and light weight persistent hosting environment for web applications. However, prior to Movable Type 3.34, FastCGI support could only be achieved by applying a number of patches to the MT source code. In 3.34, however, those patches are no longer necessary; FastCGI support has been fully integrated into the core application. Now Movable Type is capable of detecting
when it is running under FastCGI automatically and take advantage of its unique performance benefits without the user or the system administrator needing to do a thing.Because of the profound performance benefits of FastCGI and the security fixes made in Movable Type 3.34 we encourage all users to upgrade to the latest version of Movable Type as soon as possible.
Thence follows in the announcement many bullets about how spiffy FastCGI is — increased app performance, increased commenting performance, increased reliability, increased resiliency during spam attacks. Yay!
Except …
Well, MT’s documentation for how to actually get MT 3.34 to work under FastCGI is … well, frankly, pretty crappy. I am not, myself, a complete tyro at these things. I’m no UNIX or Perl expert, but I can make my way around FTP and the Control Panel and the like, and have supported by MT and other hosted applications in a relatively decent fashion.
That said … the docs are pretty crappy. The announcement above? It points to the following:
- A Flash presentation on how to upgrade to 3.34 — which doesn’t mention FastCGI, and is, in fact, the Flash presentation made for the upgrade from 3.1 to 3.2 (and the 3.34 upgrade, if from 3.33, doesn’t actually do most of what the Flash shows).
-
The Movable Type/FastCGI Installation Instructions — which, really, aren’t. Instead, it’s the 6A Development Wiki page on FastCGI. Far from a step-by-step, it’s a scattergun of various dev notes and suggestions, some of which repeat each other, some of which seem to contradict each other. The page has in turn a series of links to various articles on making MT 3.33 run with FastCGI, all of which are heavy-duty
under-the-hood style system tweaks (some of which have an update that says, “this is much simpler under 3.34 without specifics”). - MT and FastCGI benchmarks. Woo-hoo! It runs faster! That’s a help in installing thigns … not.
- The FastCGI home page — which doesn’t mention MT.
- Info (from the above) on implementing FastCGI on your web server — which, again, doesn’t mention MT.
I.e., if you were expecting something simple and straightforward on how to turn on FastCGI and then turn MT on to using it — so sorry. Despite it being the “highest recommendation” of 6A and “the future of MT,” it is clearly not just a matter of running an install script or copying over or renaming some files. Granted, the UNIX world (and FastCGI implementations) are a
legion of slightly incompatible “I did this over here and it fixed the error in those instructions over there,” but 6A is going to have to make this implementation a lot more bullet-proof and straightforward to get folks to use it (like I would still like to).
Because despite the claim “Now Movable Type is capable of detecting when it is running under FastCGI automatically and take advantage of its unique performance benefits without the user or the system administrator needing to do a thing” (even the dev wiki doesn’t claim that), I just can’t get it to work. I can’t get the “hello world” test to work. I get some cryptic errors in the server error log (some of which I’ve been able to interpret), and 500 errors from the revised scripts. I could
poke at it a lot harder, and maybe after putting in another ten or twenty hours of work I could figure out what was going on. Or maybe not. In either case, I don’t have that amount of time to invest. At least not this week.
Disappointing.
Dave…
It’s loading and I am not getting 500 errors when I try to comment or post, so I think it’s a keeper. 😀
Well, yeah, 3.34 itself is solid — and, frankly, the best thing I found to fix the problem was (a) renaming the comment script (which turned out to be as painless as renaming the trackback script), (b) looking to see who was still trying to hit the old script name, and (c) IP banning the address stubs that were doing so. Voila. Instant load reduction.
Doesn’t change my mind about (1) wanting FastCGI support, and (2) disappointment over 6A’s support of it.
I too have had lots of problems implementing FastCGI under 3.34. It’s finally working, though one (of 7) blogs is screwed up, and there are numerous errors in my site’s error log, to do with those scripts that I didn’t rename. I’m sick of reading all the “googled” posts to do with 3.34 and FastCGI and nobody has mentioned the errors I have. It seemed like such a wonderful idea, and has improved site performance measurably. Error-free would be great, and more help on the topic a must. Good luck.
Thanks. I keep checking the Dev wiki (!) but haven’t resumed my research seriously.