What is the better way to start vassals: 1. One vassal with lots of processes. This mean that one vassal will open one tcp socket and all requests are handled. 2. Multiple vassals, each with lower number of processes. In this case each vassal will open it's own socket and fastrouter will balance requests.
For now I'm using the first variant. But the queue is filled quite fast. On 25 June 2014 19:14, Gheorghe Chirica <[email protected]> wrote: > Ok, I started vassal manually, using the same config which emperor uses. > > Same error in logs: > > "Wed Jun 25 18:09:12 2014 - *** uWSGI listen queue of socket > "x.x.x.x:54679" (fd: 3) full !!! (101/100) ***" > > And because of this, fastrouter gives also lots of errors: > > [uwsgi-fastrouter key: junx client_addr: 0.0.0.0 client_port: 55762] > fr_instance_read(): Connection reset by peer > [plugins/fastrouter/fastrouter.c line 149] > > > I guess because of this queue limit of 100, requests > 100 are just > dropped? > > > > > > On 25 June 2014 18:52, Roberto De Ioris <[email protected]> wrote: > >> >> >> >> >> >> > I did not enabled on_demand mode. You mean this >> > < >> http://uwsgi-docs.readthedocs.org/en/latest/Changelog-1.9.1.html#on-demand-vassals >> >? >> > As I understand Emperor is just managing vassal processes, and vassals >> > subscribe to fastrouter and communicate via this socket I have. >> > >> > >> >> i am quite doubtful your socket is reset by the kernel to 100 (100 is the >> uWSGI default, while the linux one is 128). >> >> Try running the instance manually (without the Emperor), and strace it to >> check which listen value is passed. >> >> -- >> Roberto De Ioris >> http://unbit.it >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
