Singleshot FastCGI, other development

Encouraged by how fast Singleshot is when running as a persistant process but discouraged by the relatively scarcity of mod_python hosting, I wrote a FastCGI wrapper for Singleshot this weekend. It may be faster than the mod_python version. I feel better about it than the mod_python version, because I know exactly how many instances will get started (vs one per Apache process) and it runs out of process from apache (which means it won’t get horked by Apache2 or anything else Apache is doing). It can also in theory interface with other FastCGI aware webservers, though I haven’t tested that. It’ll be in Singleshot 2.0, though at least as experimentally as the mod_python support. My plan is to include both mod_python and FastCGI support with the 2.0 release and see if anyone other than me cares about it. I’ll be using the FastCGI support for photos.xythian.com as soon as I move it somewhere that supports FastCGI (probably Dreamhost since I already have things there but I may try TextDrive). TextDrive is appealing because it’ll let me easily host just photos.xythian.com with them without delegating xythian.com’s DNS to them. ISPs that think a domain is just a web site can be pretty irritating.

FastCGI Singleshot currently only supports ImageMagick for image resizing — it’s single threaded and it turned out having the whole process block for making thumbnails was not good for responsivness. Since Singleshot already spawned a process to run convert, it was easy enough to have it not block the main thread on the spawned converts. Since ImageMagick was also faster and still seems to have a quality edge over PIL, it was an easy decision to only support ImageMagick when deployed using FastCGI.

Singleshot FastCGI supports multiple, multiplexed connections and allows the server to reuse connections. Too bad Apache mod_fastcgi doesn’t. I still need to test the new FastCGI support with another web server, and also figure out how the current reliance on mod_rewrite rules will translate for other webservers.

My FastCGI implementation just depends on asyncore, so no new dependencies were introduced with it.

Aside from the new deploy work, I also fixed lots of little bugs. I’ll probably start putting prerelease builds up on Sourceforge soon, as soon as I take the time to write up some preliminary install docs.

Eventually I’ll probably go ahead and make a deploy option where Singleshot runs as a standalone webserver, because I can. That will almost certainly depend on Twisted so I can get all the HTTP/1.1 support without having to write it myself.