> -----Original Message----- > From: Matt S Trout [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > > 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:[EMAIL PROTECTED] > > > > > Sent: Monday, February 11, 2008 11:47 AM > > > > > To: [EMAIL PROTECTED]; 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 _______________________________________________ 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/