[Catalyst] Why use external FastCGI apps?

[Matt S Trout]

On Mon, Feb 25, 2008 at 09:35:04AM -0500, Matt Pitts wrote:
> > -----Original Message-----
> > From: Matt S Trout [mailto:dbix-class at trout.me.uk]
> > Sent: Saturday, February 23, 2008 1:18 PM
> > To: The elegant MVC web framework
> > Subject: Re: [Catalyst] Why use external FastCGI apps?
> > 
> > On Tue, Feb 19, 2008 at 09:58:05AM -0500, Matt Pitts wrote:
> > > > -----Original Message-----
> > > > From: Matt Pitts [mailto:mpitts at a3its.com]
> > > > Sent: Monday, February 11, 2008 11:47 AM
> > > > To: mitch at onsitesquad.com; The elegant MVC web framework
> > > > Subject: RE: [Catalyst] Why use external FastCGI apps?
> > > >
> > > > Although I haven't had any experience yet with *external* fastcgi,
> > I'm
> > > > feeling this approach as well, mainly because it allows me to
> "hang
> > my
> > > > hat" on the starting/stopping/reloading of apache. I'm also trying
> > to
> > > > treat an Apache vhost like an "appliance" that I can drop
> anywhere.
> > I
> > > > basically have *everything* related to a single vhost organized
> > under
> > > a
> > > > standard structure and I keep it all in Subversion.
> > > >
> > > > This way, deploying a site to a different machine is
> > > >  - get vhost "appliance" from subversion
> > > >  - symlink vhost conf file into apache vhosts.d
> > > >  - sync logs if necessary
> > > >  - apache reload
> > > >
> > > > I know my model isn't perfect, but if I use external fastcgi then
> > it
> > > > adds an "easily looked over" step - create/symlink some fastcgi
> > init
> > > > script.
> > > >
> > > > The only things that will definitively push the use of external
> > > fastcgi
> > > > are: if I cannot get mod_fcgid to work with PAR files; or if I'm
> > happy
> > > > with external fastcgi testing/memory usage and can integrate it
> > into
> > > my
> > > > vhost model without too much unhappiness.
> > >
> > > Well, external FCGI ended up winning me over, mainly because I
> > couldn't
> > > get mod_fcgid to launch from a PAR.
> > > However, I must confess that I don't mind the approach now as I have
> > > built init scripts and organized things
> > > so that they are sane to me. As Yuval said, this does reduce the
> > config
> > > mess.
> > >
> > > If anyone is interested here is my setup...
> > >
> > >  - Apache 2.2 proxy frontend w/ proxy_balancer and its manager
> > > interface; mod_cband for throttling and its live traffic interface
> > >  - 2 Apache 2.2 backends each doing static file serving and external
> > > FCGI to local Cat apps
> > >
> > > When I do updates I just use the proxy_balancer manager interface to
> > > disable the host I'm going to update and do the switch-a-roo.
> > 
> > Part of the point of using external to me is not needing that stage -
> I
> > bring
> > up a new external FCGI, change an apache config symlink to point to
> the
> > new one, apachectl graceful then shut down the old external FCGI.
> > 
> > At no point is the node not serving requests, which can be extremely
> > handy
> > if you're heavily loaded. Also means you can flip all servers across
> > simultaneously, which can be important for some updates.
> 
> Yes, I quickly realized the limitation with my setup and rewrote my FCGI
> init script to have a simple versioning scheme. Each time it's run as
> "fcgi.init start" it actually starts up a brand new instance from the
> PAR (new PAR temp folder, new socket) and then does "ls -sf" to repoint
> the ExternalFCGI socket to the new "version". When it's called as
> "fcgi.init restart" is does "fcgi.init start; fcgi.init stop-previous"
> which DWIM.
> 
> I realize this may not be as sane as rewriting the apache config to
> point to the new socket, but it's working well for me. I've run some
> rudimentary tests against it with ab and with a concurrency of 5 during
> the "fcgi.init restart" process I've only gotten one failed request in
> my tests. One day I'll probably get annoyed with it and rewrite it again
> to update the apache config rather than just overwrite the socket
> symlink, but for now it works for me.

Neat approach.
 
> Thanks again for all the input.

Any chance you could repay in kind by writing up what you ended up with
on the wiki?

Using PAR + external fcgi this way is an interesting deployment option and
I think people would be interested in the process - if nothing else the
work you did to get your PAR built would be worth showing off.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/