[zeromq-dev] Design advise

[Yu Dongmin]

Nishant,

As you know, Router does fair-queuing at the receiving. But 0MQ is so fast that the first requests can be delivered to the workers before the second request.

You should invent a credit based control. Please refer the guide about an example of the credit based control on the FileMQ.

Thanks
Min

On Dec 29, 2012, at 5:58 AM, Nishant Mittal <nmittal at rblt.com> wrote:

> Yes, and that is what I have implemented.. however, I am pointed out a different scenario
> 
> 
> On Fri, Dec 28, 2012 at 3:55 PM, Harsh Doshi <hardos at gmail.com> wrote:
> The guide has an example for doing load balancing using a router-dealer sockets
> 
> Harsh
> 
> Sent from IPhone
> Pardon the typos 
> 
> On Dec 28, 2012, at 11:25 AM, Nishant Mittal <nmittal at rblt.com> wrote:
> 
>> Router does fair-queuing but i think whats happening is that all msgs from the 1st client are received and stored in the router's internal queue thats why the 2nd client has to wait.
>> 
>> and for that reason, "i think", your idea wouldnt work as well as the messages are already in router's internal queue.
>> 
>> thanks
>> 
>> 
>> On Fri, Dec 28, 2012 at 2:21 PM, Claudio Carbone <erupter at libero.it> wrote:
>> My stupid idea is a "man-in-the-middle":
>> Put a loop in your queue doing a round-robin on the request pool.
>> Like forwarding 5 reqs for each client each turn: if a client sends a lot of requests, it just has to wait until the next loop.
>> 
>> By the way shouldn't the router already be doing some loadbalancing ?
>> I'm really not a super zmq expert.
>> 
>> Claudio
>> -- Sent from my ParanoidAndroid Galaxy Nexus with K-9 Mail.
>> 
>> Nishant Mittal <nmittal at rblt.com> wrote:
>> In my use case, 
>> - I have a queue (a proxy with ROUTER in the front and DEALER in the back).
>> - Client has a DEALER socket that connects to the ROUTER in the proxy above. not using as I want the client to be able to send multiple jobs without waiting for a response
>> - Worker has a REP socket that connects to the DEALER in the proxy above
>> - this is working great, however, a design goal is to not let 1 client block other clients from sending and receiving responses which is what is happening at the moment. If the first client sends a lot of requests BEFORE the second client started sending its requests then first all the requests of the first client are served and then the second.
>> 
>> How can I improve this design so if 1st client sent 10000 requests and then 2nd came along and sent 1 request, it doesn't have to wait for the 10000 requests to finish?
>> 
>> I guess one solution would be to lower the high watermark so the 1st client would be blocked from sending more but feel that would hurt performance/scalability.
>> 
>> thanks
>> Nishant
>> 
>> 
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> 
>> 
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> 
>> 
>> 
>> -- 
>> Nishant Mittal            
>> Director, Product Development
>> Rosenblatt Securities Inc.
>> 20 Broad Street
>> New York, NY 10005            
>> 
>> Direct: 212-607-3159
>> Mobile: 646-504-2629
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> 
> 
> -- 
> Nishant Mittal            
> Director, Product Development
> Rosenblatt Securities Inc.
> 20 Broad Street
> New York, NY 10005            
> 
> Direct: 212-607-3159
> Mobile: 646-504-2629
> _______________________________________________
> 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/20121229/f6970456/attachment.htm>