On Fri, May 29, 2009 at 11:49:45AM -0500, Stephen Clouse wrote: > On Thu, May 28, 2009 at 5:48 PM, Stephen Clouse > <stephenclo...@gmail.com>wrote: > > > Commenting that out, then theoretically (note that this is totally untested > > at the moment, but I intend to tomorrow): > > > > Well, it was worth a try, but obviously too much voodoo. Catalyst complains > about not being able to find //_DISPATCH. Something internal gets fried > with the delayed setup call. > > This, on the other hand, works perfectly, although less memory-efficient -- > one full compile of Catalyst per vhost. Even so, this should be a win over > the traditional FastCGI deployment (since the optree will at least still be > shared within the vhost interpreter pool).
I doubt it. FastCGI isn't "traditional" for Catalyst - it's what people switched to because mod_perl almost never has a better memory/performance profile. Especially since most of the mod_perl cleverness relies on interpreter cloning, which unshares a huge amount of stuff that -can- be shared across a fork. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.uk http://shadowcat.co.uk/blog/matt-s-trout/ _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/