spawn-fcgi-1.6.0rc1-r16 prerelease]

[mike]

On Sun, Mar 8, 2009 at 2:02 PM, Icy -- <lists at ruby-forum.com> wrote:

> That is up to the application, not spawn-fcgi.
> It could do threading, have multiple worker processes or whatnot.

Grzegorz knows best. Looks like he has replied.

> I have never used fcgiwrap and in fact just discovered it. As I
> understand it, it uses fcgi to then spawn cgi processes? Why not code
> the application as a FastCGI one? That would be way faster in terms of
> performance.

Oh, I prefer PHP (and I guess anything else with FastCGI) - however, I
have to support bugzilla, mailman and other older apps right now. I
don't like it, but there are no good replacements out there that my
customers have found yet (I was thinking of trying to rewrite mailman
in PHP in fact)

> The only reason you would need that is to either run CGI apps on a
> remote host or to overcome the lack of cgi support in nginx.

Correct - nginx doesn't natively support it.

> And all you find via google are invalid bugreports. Saying something can
> be found on the internet doesn't make it true.

spawn-fcgi was not properly recycling php engines (i.e.
PHP_MAX_FCGI_REQUESTS or whatever) when i was using it, i was able to
validate it. i wound up going back to a custom php -b solution until i
found php-fpm. so there -are- bugs.

> You can of course (as I said earlier) start multiple processes by
> calling spawn-fcgi multiple times (with different command options for
> the address).
> But even a single process could handle many concurrent requests (see
> lighty).
> There are many ways (like I wrote before too) to do so: threads, child
> processes, multiplexing...
> Telling spawn-fcgi to spawn like 10 processes is not possible because
> how should it know which addresses to bind to?

I have no clue.

Can Grzegorz get in here and you two can hash out how it works? :)