[Catalyst] Why use external FastCGI apps?

[Matt Pitts]

> -----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.

Thanks again for all the input.

v/r

-matt pitts