On śro, paź 21, 2009 at 05:15:58 -0700, Roger Hoover wrote:
> Hi Grzegorz,
>
> The other way to group identical programs is to set numprocs > 1. Also, you
> have some control over the name of the processes with the process_name
> config option. For example,
>
> [program:cat]
> command = /bin/cat
> process_name=%(program_name)s_%(process_num)s
> numprocs = 2
>
> Then you would start them as cat:cat_0 and cat:cat_1
Yes. And I'd like to call them simply "cat_0" and "cat_1". Is there any
deeper reason it's not possible?
> On the nginx mailing list, you mentioned that your module was not using
> fcgi-program. Maybe you could explain more about the reasons? I tend to
> think that it should use fcgi-program b/c it allows all the processes in the
> fcgi pool to share a single socket. I would expect that to make the nginx
> module simpler if it does not have to load balance over multiple sockets,
> one for each fcgi process. Also, it will make for much better load
> balancing because when all the processes share a socket, the kernel will
> distribute connection requests to each process as soon as the process is
> ready to accept() and it guarantees that the connections are delegated in
> the order they were received. If connection requests start queueing up on
> the shared socket, the nginx module can trigger more processes to be spawned
> and they can immediately start accepting from the existing connection queue
> on the shared socket.
>
> Without a shared socket, the nginx module has to do it's best to load
> balance all the sockets but it may not end up sending the connection to the
> socket with the smallest queue. Also, if one socket connection queue starts
> backing up and the module triggers another process to be started, the new
> process will create it's own socket and be able to take new requests but
> cannot accept connections that are already queued on existing sockets.
>
> Please let me know if I'm mistaken here. Thanks,
QFT. You're basically 100% correct here. The problem is purely in
implementation. To keep things simple, we generate program names from
Nginx upstream name, which may not contain a colon. So we cannot refer
to programs in groups at all, including pools of FastCGI servers. This
forces us to either:
a) implement explicit support for program groups in our module (which I
believe is supervisord's detail and outside world need not know about
it)
b) go the easy route, spawn a pool of independent servers on different
sockets
If we could "start cat_1" given the config you posted, we'd be set, as
in:
upstream cat_ {
supervisord http://127.0.0.1:9000 user pass;
server unix:/tmp/sock;
server unix:/tmp/sock;
fair;
}
The load balancing logic would be mostly useless here (and mistaken
about individual backends' load) but we don't care as the real load
balancing is done in the kernel and the overhead is minimal. Also we
could easily implement a dummy "load balancer" (more like process
manager interface) for multiple servers on a single socket.
BTW, and straying a bit from the original topic, it's my personal pet
peeve -- why did FastCGI do the right thing and standardise on receiving
the listening socket from high above but no application server using
HTTP I've seen can do it? It solves so many problems cleanly.
Best regards,
Grzegorz Nosek
_______________________________________________
Supervisor-users mailing list
[email protected]
http://lists.supervisord.org/mailman/listinfo/supervisor-users
