[zeromq-dev] Exploring 0mq 3.0 - lack of monitoring

[Andrew Hume]

i think i still do not understand.

flow control != monitoring

i think this is yet another manifestation of the old confusion between
routing and job scheduling. the issue is how much work it takes to deal with
a message. when this is large (say many seconds), then the simplest (and near
optimal) approach is to have workers ask for teh next job/message.
(this is also a degenerate case of credit-based flow control with a buffer size of 1).
the overhead is insignificant.

when the work is tiny (say milliseconds to microseconds per message), then
everything needs to be done in the routing (that is, within zeromq) because you can't afford the
overhead to do it in the application. BUT, this scenario is typically associated with
large volumes, so the standard load balancing should work just fine.

having said all that, ilja, what monitoring would you want?

	andrew

On Nov 2, 2011, at 12:59 AM, Ilja Golshtein wrote:

> Andrew,
>  
> looks like I did not express what I mean clear enough.
> My point is Credit-Based Flow Control approach suggested by Pieter is not always affordable,
> because it involves significant performance loss.
> Basically,  Credit-Based Flow Control is an external device to analyze gasoline consumption profile,
> requires a couple of litres per kilometer.
> My suggestion is to utilize some equipment of the car to have this job done with smaller extra.
>  
> Guys who care about monitoring are usually performance-focused (like me).
> And I think it would be better from performance point of view to have some monitoring facilities inside 0mq.
>  


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
andrew at research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111105/dfce55e8/attachment.htm>