[zeromq-dev] Multiple clients with REQ/REP

[Goswin von Brederlow]

On Thu, Jul 24, 2014 at 08:30:40PM -0500, Gregg Jensen wrote:
> I currently using zeromq 3.2.3 and will be upgrading to the latest
> soon, but for now my question relates to this older version.
> 
> I have been use the REQ/REP socket types for single client to single
> server with great success.  And according to the guide now that I want
> to move up to the final goal of multiple clients to a single server,
> I was under the impression that I am supposed to changed the clients
> to include the identity, and then use a ROUTER to DEALER proxy which
> delivers to REP worker processes that have been spawned off in
> separate threads.  I have code that will do this, however I have some
> problems with the processing in the threads.  But, that is not the
> question.  I backed out the code that does the ROUTER/DEALER/workers
>  and went back to just the one REP socket on the server that spawns the
> processing on a thread upon recv.  I went back to run my multi-client
> test and bingo it all worked great.  Therein lies my question.  How
> many client REQ connections will the standard REP socket handle?  Can
> I leave my code with just REQ/REP and not move to
> REQ->ROUTER/DEALER/workers?  That is, will it scale up to 100?s,
> 1000?s or  even 100,000s (given good hardware) connections?  Will the
> client connections all stay aligned with the socket connection they
> make the request to?  If so, then why would I want that pattern on the
> server of ROUTER to DEALER (proxy) out to workers in separate threads?

REQ/REP work just fine with multiple peers. The only restriction is
that you have a strict request/reply/request/reply/request/reply
pattern. You can not handle multiple requests in parallel or send
replies out of order.

Also the different socket types in zmq are pretty much all the same
concerning scalability I think. If zmq can't handle N peers on a REP
socket then it won't be able to handle N peers on a ROUTER either.
And N is > 1000 for sure.

The scalability problem with 100000 peers will be in your server. It
can only handle one request at a time and if a request takes time that
will block all other peers. Worse if a request has to wait, e.g. to
extract some data from a database.

So when a single request has to wait or can't be parallelized to use
all cores then you can improve your scalability by switching to a
REQ/ROUTER setup and handle multiple requests in parallel. You can
also improve each clients performance by switching to DEALER/ROUTER
and issuing multiple requests in parallel, if your problem allows for
that.

Note: If you like me are using python then beware that python has a
global lock allowing only one python thread to run at any given time.
Multiple threads only help if threads block waiting for something.

MfG
	Goswin