Hi Joe, > OK, that part is starting to make more sense now. I'm playing around > with putting my service definitions in SRV RR records (actually > DNS-SD, but same concept). The RFC [1] spells out a load balancing > algorithm for client programs based on the weight and priority of each > record. It's not round robin, but similar. The idea is that the > person registering the service knows the attributes of the hardware > that it's running on and can hint to the client agent that X node has > more capacity than Y node although they are both offering the same > service. Just thinking out loud, but is there a way to provide those > hints to 0MQ or should we just trust that 0MQ is better at dynamic > load balancing than we could hope to be using deployment time hints?
0MQ does a dumb load-balancing (round robin). The assumption is that we don't know processing capacity of each peer in advance. If a particular peer is not able to keep up, it's queue gets filled up and no more messages are dispatched to it. Once it processes some messages, and thus empties the queue, we can add the connection back to round-robin. If we knew the weights in advance (as specified with RFC 2782) we can in theory write a load-balancing that would hit the queue limits less often. However: 1. Do we even care? 2. User has to manually set the weights = work = increased cost. 3. There's no guarantee that user will set the weights so that they reflect the reality. >> When one of them fails, up to ZMQ_HWM requests is queued for it and once >> the limit (HWM) is reached it no more request will be sent to that >> server. Once it gets back online queued requests will be sent to it and >> load-balancing starts to dispatch new requests to it automatically. > > The part that confuses me about this is in a traditional RPC scenario > you may be calling services that have side effects or that lack > idempotence, per se. You'd want the message to be handled by the > first reachable service provider and no others. Unless I > misunderstand what you're saying, it seems counter-intuitive that > RPC-style messages would queue up rather than failover to alternate > instances or fail fast when there are no reachable instances? The question is: How do you know the instance is reachable. You can never tell before you actually get a reply from it. To get a reply you have to send a request. That means that at least 1 message (the request) is "queued" for delivery to the service with unknown availability. There's no way to avoid that. As for why 0MQ allows more than one message in the queue - it's for efficiency's sake. Having at most one message sent to particular instance means that processing of requests proceeds in lock-step fashion, which can be severely inefficient, especially in scenarios where there's non-negligible roundtrip time between client and the service. > I probably need to go back and read the whitepapers again now that I'm > becoming more familiar with the concepts. Please, keep the list posted about your experience with 0MQ and RFC 2728. The matter is of critical importance for further development of 0MQ and the more experience we as a community can gather about addressing and naming issues, the better. Martin _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
