[Catalyst] Why use external FastCGI apps?

[Matt Pitts]

> -----Original Message-----
> From: Matt S Trout [mailto:dbix-class at trout.me.uk]
> Sent: Saturday, March 08, 2008 10:42 AM
> To: The elegant MVC web framework
> Subject: Re: [Catalyst] Why use external FastCGI apps?
> 
> 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.

I'm honored by the invitation and I got my boss to OK it. So where
should it exist in the Wiki and what should it be called? "PAR
Deployments w/ Apache and FastCGI"?

v/r

-matt pitts