Thank you very much Jeff and Joe. Based on your discussion I will carefully
consider each processor on its own merits and in terms of what my
priorities are for my workflow at that point before I make changes and
trade-offs between latency and throughput.
Jim
On Fri, Apr 7, 2017 at 2:40 PM, Joe W
Jeff,
Not really though - your comment is true. Or it could be true if it
isn't. What I mean is that the slider is really a way to the let the
user 'hint to the framework' their preference and how dedicated to
that preference they are. We will continue to use that information to
make under the
It looks like the way I think about it might be a bit off base. :)
On Fri, Apr 7, 2017 at 2:31 PM Joe Witt wrote:
> The concept of run duration there is one of the ways we allow users to
> hint to the framework what their preference is. In general all users
> want the thing to 'go fast'. But w
The concept of run duration there is one of the ways we allow users to
hint to the framework what their preference is. In general all users
want the thing to 'go fast'. But what 'fast' means for you is
throughput and what fast means for someone else is low latency.
What this really means under t
James,
The way I look at it (abstractly speaking) is that the slider represents
how long a processor will be able to use a thread to work on flowfiles
(from its inbound queue, allowing onTrigger to run more times to generate
more outbound flowfiles, etc). Moving that slider towards higher
through
I see that some processors provide a slider to set a balance between
Latency and Throughput. Not all processors provide this, but some do. They
seem to be inversely related.
I also notice that the default appears to be Lower latency, implying also
lower throughput. Why is that the default? I would
