[zeromq-dev] zmq load balancing from the Tornado event loop

[Whitney Jackson]

> I believe this is caused by the "recreation" of the zmq instance on every
request which probably is messing with the RR algorithm. If there a better
way to do this?

You're on the right track. Since, you create a new a new zmq REQ socket for
every HTTP request and only ever use it once, the second endpoint never
gets a chance to be used.

One solution is to assign the zmq REQ socket to TestHandler when you create
your web.Application. This way you re-use the same socket instead of
creating a new one for every request. Attached is a patch that makes this
change to your pastebin code.

Whitney


On Sat, Jan 19, 2013 at 1:07 PM, Thomas Jackson <jacksontj.89 at gmail.com>wrote:

> I'm fairly new to zeromq and have been trying to get some more background
> in how stuff works, as suuch I've been running through a few examples in
> the pyzmq github repo. I was working on the async web example (
> https://github.com/zeromq/pyzmq/blob/master/examples/eventloop/asyncweb.py)
> and was working on extending it to have a pool of processes for the
> "slow_responder" instead of a single thread. My changes are here:
> http://pastebin.com/h2vhrQxu. This issue that I've been running into is
> that it seems that all requests for the slow_responder go to a single
> process, instead of being load balanced across both of them. I believe this
> is caused by the "recreation" of the zmq instance on every request which
> probably is messing with the RR algorithm. If there a better way to do
> this? Or would I need to have my own mechanism for distributing the load to
> the correct sockets?
>
>
> Thomas Jackson
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130120/bf9867a6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 1543 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130120/bf9867a6/attachment.obj>