[Zope] why will FastCGI not be supported in the Future.

[Sascha Welter]

(Mon, Nov 28, 2005 at 08:28:56AM -0500) zope-request at zope.org wrote/schrieb/egrapse:
> From: Gerhard Schmidt <estartu at ze.tum.de>
> I'm a little bit puzzled why there are growing Number of Mails telling
> that the support for FastCGI will disappear in the future. Why is this.
> 
> I am running multiple sites that are hybrides of apache/php and zope. It's
> very easy to set up such a config with mod fastcgi and Apache. 

Our perception of reality seems to differ a lot.

Setting up hybrid sites with RewriteRules / mod_rewrite and VHM in Zope
is incredible easy, much easier than configuring fastCGI in httpd.conf.
(And I'm not even counting having to compile fastcgi and hooking it into
apache.)

In helping relative newbies (to zope|apache) to configure their "zope
gehind apache" setup on #zope (irc.freenode.net)I found out that life
is much easier with 2 rewriterules. You will need rewriterules anyway
if you want to force /manage access to https. And afer the rewrite rule
"witch" was running, "zope behind apache" support on #zope has dwindled
down a lot.

> It works
> just fine and very stable, even on heavy load.

Here my experience differs a lot from yours it seems.

> The posibility to Easy integrate Zope in existing apache/php server was one
> of our main reasons to use Zope.
> 
> I know there is a way to do just the same with mod_proxy, but mod_proxy does
> open new connection for every request while fastcgi uses the same connection
> for all requests. The is no problem on low load. But with growing load, this
> can become a Problem.

This is the fun part. Only a couple of weeks ago I grew bored having to
restart / reinvestigate / sacrifice dead chicken for our one legacy zope
instance that was run through fastcgi. Not really high load on the
server, but high load on the admin due to apache? zope? getting stuck 
somehow. 

> Date: Mon, 28 Nov 2005 14:05:22 +0100
> In none of the Postings is an reason why FastCGI ist bad and therefore not 
> supported in the future. Just to say "so it is" is not an Answer. 

Experiences may differ, see above. For me it's "fastcgi, never again". 
It likely was great at some point in the past, but there is better stuff
now. I value the undisturbed time that I can advance our company codebase
too high, I don't want to be interrupted all the time with "XY hangs".

As someone else mentioned, it's up to you!

Regards,

Sascha