[zeromq-dev] Load balancing REQ/REP sockets

Brian Granger ellisonbg at gmail.com
Wed Mar 17 23:57:39 CET 2010


Martin,

> The whole XREQ/XREP business is still messy. If you absolutely need it at
> the moment you can use XREQ to connect and load-balance messages to mutliple
> REPs. That way you'll get what you need without a need to do any special
> processing on the REP side.

I have tried the XREQ -> multiple REP socket topology.  The requests
are load balanced to the REP sockets and there can be multiple
requests in the air at a time.  BUT, the notion of load balancing is a
bit odd.  The load balancing logic is here:

http://github.com/sustrik/zeromq2/blob/master/src/lb.cpp#L90

The idea is that the next send will happen on the current+1 active
pipe.  Basically, this round-robins the requests to the different REP
sockets.  But, in my mind, this strategy is not a completely useful
load balancing.  Here is why.  Some requests may take longer/shorter
for the REP socket to process.  With the current approach, a REP
socket that handles a very short request, will have to sit there doing
nothing until its turn comes again.  Likewise, a REP socket that gets
a very time consuming request will continue to get new requests,
though it is busy.

A more useful and dynamic load balancing approach would be would be
the following:

* Look at the current + 1 pipe.  If it is not servicing a request, use it.
* If the current + 1 pipe is busy, see if the current + 2 pipe is
servicing a request.  If not use it.
* Continue through the active pipes.  If all are busy, use the current
+ 1 anyways.

Is there a way of telling if a pipe is servicing a request?  Would it
make sense to implement this?  This more dynamic load balancing would
be incredibly useful.

Cheers,

Brian

> However, it's experimental functionality, so no warranty is given :)
>
> Martin
>
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list