<br><div class="gmail_quote">On Thu, Oct 22, 2009 at 1:37 AM, Grzegorz Nosek <span dir="ltr"><<a href="mailto:root@localdomain.pl">root@localdomain.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On śro, paź 21, 2009 at 05:15:58 -0700, Roger Hoover wrote:<br>
> Hi Grzegorz,<br>
><br>
> The other way to group identical programs is to set numprocs > 1. Also, you<br>
> have some control over the name of the processes with the process_name<br>
> config option. For example,<br>
><br>
> [program:cat]<br>
> command = /bin/cat<br>
> process_name=%(program_name)s_%(process_num)s<br>
> numprocs = 2<br>
><br>
> Then you would start them as cat:cat_0 and cat:cat_1<br>
<br>
</div>Yes. And I'd like to call them simply "cat_0" and "cat_1". Is there any<br>
deeper reason it's not possible?<br></blockquote><div><br>For a config like this,<br><br>[fcgi-program:test]<br>command=/foo//bar/test.fcgi<br>socket=unix:///var/run/fcgi/test.socket<br>process_name=foo_%(process_num)s<br>
numprocs=2<br><br>[program:test2]<br>command=/foo//bar/<a href="http://test.pl">test.pl</a><br>process_name=foo_%(process_num)s<br>numprocs=2<br><br>There has to be a way to disambiguate between test:foo_0 and test2:foo_0. This issue seems to be that nginx will not allow backend names to contain ":"? Is there no way to translate between a name used in nginx and the name used in supervisord? Maybe the nginx backend name could be "test__foo_0" which gets mapped to "test:foo_0" when doing supervisord XMLRPC calls?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> On the nginx mailing list, you mentioned that your module was not using<br>
> fcgi-program. Maybe you could explain more about the reasons? I tend to<br>
> think that it should use fcgi-program b/c it allows all the processes in the<br>
> fcgi pool to share a single socket. I would expect that to make the nginx<br>
> module simpler if it does not have to load balance over multiple sockets,<br>
> one for each fcgi process. Also, it will make for much better load<br>
> balancing because when all the processes share a socket, the kernel will<br>
> distribute connection requests to each process as soon as the process is<br>
> ready to accept() and it guarantees that the connections are delegated in<br>
> the order they were received. If connection requests start queueing up on<br>
> the shared socket, the nginx module can trigger more processes to be spawned<br>
> and they can immediately start accepting from the existing connection queue<br>
> on the shared socket.<br>
><br>
> Without a shared socket, the nginx module has to do it's best to load<br>
> balance all the sockets but it may not end up sending the connection to the<br>
> socket with the smallest queue. Also, if one socket connection queue starts<br>
> backing up and the module triggers another process to be started, the new<br>
> process will create it's own socket and be able to take new requests but<br>
> cannot accept connections that are already queued on existing sockets.<br>
><br>
> Please let me know if I'm mistaken here. Thanks,<br>
<br>
</div>QFT. You're basically 100% correct here. The problem is purely in<br>
implementation. To keep things simple, we generate program names from<br>
Nginx upstream name, which may not contain a colon. So we cannot refer<br>
to programs in groups at all, including pools of FastCGI servers. This<br>
forces us to either:<br>
a) implement explicit support for program groups in our module (which I<br>
believe is supervisord's detail and outside world need not know about<br>
it)<br>
b) go the easy route, spawn a pool of independent servers on different<br>
sockets<br>
<br>
If we could "start cat_1" given the config you posted, we'd be set, as<br>
in:<br>
<br>
upstream cat_ {<br>
supervisord <a href="http://127.0.0.1:9000" target="_blank">http://127.0.0.1:9000</a> user pass;<br>
server unix:/tmp/sock;<br>
server unix:/tmp/sock;<br>
fair;<br>
}<br>
<br>
The load balancing logic would be mostly useless here (and mistaken<br>
about individual backends' load) but we don't care as the real load<br>
balancing is done in the kernel and the overhead is minimal. Also we<br>
could easily implement a dummy "load balancer" (more like process<br>
manager interface) for multiple servers on a single socket.<br>
<br>
BTW, and straying a bit from the original topic, it's my personal pet<br>
peeve -- why did FastCGI do the right thing and standardise on receiving<br>
the listening socket from high above but no application server using<br>
HTTP I've seen can do it? It solves so many problems cleanly.<br></blockquote><div><br>Hmm...great question. I've never looked at Apache internals but assumed it worked that way.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Best regards,<br>
<font color="#888888"> Grzegorz Nosek<br>
</font></blockquote></div><br>