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
[email protected] (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
