[zeromq-dev] queue overhead

[sven]

... found some ==>old<== (but working) snippet of a queue device
that dispatches to several workers using pub and req/rep sockets.


warning: the workers have to supply those "READYforWORK" message
dummies to care for the "ready/busy list" in the queue. 

I attached my
modified code for zmw's queue device ... maybe it helps you a bit
;o)

Am 2014-07-27 20:13, schrieb Justin Karneges: 

> I have a "stable"
(in the addressing sense) worker that I want to take 
> advantage of
multiple cores. So, I run N instances of this worker, where 
> N is the
number of cores on the host machine, and each worker binds to 
> its own
socket. Components that wish to make use of this worker service 
>
connect to all N worker instances.
> 
> Unfortunately this is a little
awkward. The connecting components must 
> be configured with the N
socket specs. And it's hard to automate this, 
> since even if the
connecting components could generate socket specs 
> programmatically,
this still requires knowing the number of cores of the 
> remote
machine.
> 
> What I'd like to do is put an adapter component in front
of the N worker 
> instances (on the same machine as the worker
instances) that binds to a 
> single socket. It would route to the N
workers, and this is easily done 
> since the adapter lives on the same
machine and knows the number of 
> cores. Connecting components could
then simply connect to this adapter, 
> and not need to care about the
number of remote cores.
> 
> The question I have is what kind of
overhead this introduces. An MxN set 
> of connections between M remote
components and the N workers seems like 
> it would be far more
efficient than M->1->N, which looks like a 
> bottleneck. But maybe in
practice, if the routing is very simple, then 
> it becomes
negligible?
> 
> Justin
> 
>
_______________________________________________
> zeromq-dev mailing
list
> zeromq-dev at lists.zeromq.org
>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev [1]




Links:
------
[1] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140728/7e9c59b8/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ownZmqQueue.h
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140728/7e9c59b8/attachment.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ownZmqQueue.cpp
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140728/7e9c59b8/attachment.ksh>