[Zope-dev] FastCGI question

[John Eikenberry]

I believe you can stop this just by changing the PCGI_PUBLISHER variable in
your Zope.cgi to a directory, /dev/null or something.

We do this for all our site, using the mod_pcgi apache module. It works
fairly well... at least well enough for us not to consider changing yet.

Michael Olivier wrote:

> At 07:33 PM 3/23/2001 -0800, sam gendler wrote:
> >I haven't used Zope to any significant degree in over a year.  When I
> >was last using Zope regularly, FastCGI still had some stability issues,
> >which made it difficult to use in a production environment. However, I
> >have always felt that FastCGI was the better solution when choosing
> >between proxy, pcgi and fastcgi, from a theoretical standpoint.  Can
> >someone comment as to the efficacy of using FastCGI to implement an
> >interface between my HTTP enabled application and current version of
> >Zope, or should I use one of the other solutions.
> 
> Hi Sam and others --
> 
> I was about to ask the same question myself.  I'm also wondering about 
> switching solutions to FastCGI or proxy.  I read on the zope web site that 
> zope.org is using the proxy approach.  Can someone in-the-know please shed 
> some light?
> 
> I'm using PCGI (2.0a4) with ZPublisher and while it's worked reasonably 
> well for very small traffic levels, I have recently run into an issue where 
> lots of extra pcgi_publisher.py processes get started until the system 
> grinds to a halt.  I found two old postings from others (John Eikenberry, 
> Craig Allen) about this problem, including this one:
> 
> http://classic.zope.org/pipermail/zope/1999-April/003926.html
> 
> ... and am wondering if it's been solved and if there's a later release 
> (Zope 2.3 stable has pcgi 2.0a4 still).
> 
> Thanks!
> Michael
> 

-- 

John Eikenberry [jae@kavi.com]
______________________________________________________________
"A society that will trade a little liberty for a little order
 will deserve neither and lose both."
                                          --B. Franklin