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 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, Roger On Wed, Oct 21, 2009 at 12:02 PM, Grzegorz Nosek <[email protected]>wrote: > Hi, > > I'm sending this mail after a brief discussion about an upcoming Nginx > web server module we're sponsoring. Its purpose is to manage processes > by communicating with supervisord in response to varying load. I have a > question about program groups: AFAIK program names have to be globally > unique, so referring to a group member by its unqialified _program_ name > should be sufficient, no? As it stands, in a config like this: > > [program:cat0] > command = /bin/cat > > [program:cat1] > command = /bin/cat > > I can start, restart etc. the programs by calling them "cat0" and "cat1" > in the XMLRPC interface. But if I add: > > [group:herd] > programs = cat0,cat1 > > I now need to call them "herd:cat0" and "herd:cat1", which prevents me > from managing them using my Nginx module (it has some restrictions on > allowed program names). Is there a design decision behind this? Or is > this subject to change before 3.0 final comes out? > > Best regards, > Grzegorz Nosek > _______________________________________________ > Supervisor-users mailing list > [email protected] > http://lists.supervisord.org/mailman/listinfo/supervisor-users >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
