spawn-fcgi-1.6.0rc1-r16 prerelease]

[Icy --]

mike wrote:
> So I can launch with a single command line
> 
> spawn-fcgi -some -options some-other-cgi-stuff-than-php here
> 
> and it will allow more than one concurrent connection?

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

> 
> I think the latest version might have mentioned supporting something,
> but I'd be looking at leveraging it to manage fcgiwrap, and I don't
> want to have to launch one spawn-fcgi command for every individual
> amount of requests I intend.
> 
> i.e.
> 
> I want a pool of fcgiwrap resources available using a single command
> line for a specific website. I want to give it a specific user/group
> ID to run as. (or anything else like fcgiwrap, basically I want to run
> non-PHP CGI scripts (perl, compiled CGI) from nginx)
> 
> It sounds like the latest updates to spawn-fcgi might help this become
> a reality. Did you say you maintained the project? Have any command
> line options that I can try to make this happen? I want to be able to
> support say, 10 concurrent requests. In PHP that would translate
> roughly to 10 php children (-C 10 I think?)
> 
> Do I have to do this 10 times:
> spawn-fcgi -a -b -c /usr/local/bin/fcgiwrap
> 
> Or can I launch it just once with some parameters?

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

Jim Ohlstein wrote:
> The biggest problem is still that spawn-fcgi is known to crash and hang 
> - separate issue, I know. There are lots of references on it. Consult 
> Professor Google and you'll find many. I'd start with 
> http://www.google.com/search?q=spawn-fcgi+crash and 
> http://www.google.com/search?q=spawn-fcgi+hang. I haven't tried using it 
> in a year or more. Perhaps it's improved in that regard but I'm 
> reluctant to use it in a production environment when php-fpm is just 
> about bullet-proof as it gets. Of course that assumes that development 
> of php-fpm continues as it's presently a one man show AFAIK. Now I'm 
> aware that this doesn't happen on every system but it happens a lot and 
> it has happened to me.

And all you find via google are invalid bugreports. Saying something can 
be found on the internet doesn't make it true.
Again I think you guys completely misunderstand the role of spawn-fcgi.
It sets up some sockets and spawns a processes. That's basically it.
It is in NO way involved with handling the requests. If something 
crashes or hangs then that's the fault of the application. PHP in this 
case (and it has been known to do so in past releases).
This is not spawn-fcgi's fault. After spawning the application, 
spawn-fcgi is no more around normally. How can something that is not 
running cause such problems?

> Aside from that, even though fcgiwrap is capable of running several 
> processes simultaneously, spawn-fcgi will only start one. I may be wrong 
> but I believe that's an inherent limitation of spawn-fcgi's command 
> options.

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?
-- 
Posted via http://www.ruby-forum.com/.