river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: TaskManager
Date Fri, 01 Jul 2011 20:14:36 GMT
On 7/1/2011 2:44 AM, Patricia Shanahan wrote:
> On 6/30/2011 11:38 PM, Dan Creswell wrote:
>> On 1 July 2011 03:22, Gregg Wonderly<gregg@wonderly.org> wrote:
>>> On 6/30/2011 9:02 PM, Patricia Shanahan wrote:
> ...
>>>> loadLevel permits specification of a ratio between threads and tasks, so
>>>> that threads are only created up to e.g. one third of the number of
>>>> tasks. I'm not sure that is a really good idea. It means leaving tasks
>>>> to wait even if we could create another thread.
>> Yes, but tasks are waiting because you're choosing to limit resources.
>> That always happens. The choices are to increase the limit and utilise
>> more processor (assuming you have it) or have fewer tasks (often a
>> function of user-load so needs admission control etc to make that
>> stick).
>>> I don't like this thought at all in a distributed system. A vast majority
>>> of tasks really need to be invoked immediately to maintain a reasonable
>>> chance at throughput.
>> Equally a vast majority of tasks can only have a reasonable chance of
>> throughput in the presence of sufficient resource. The point of
>> TaskManager is to control resource consumption (including processor
>> utilisation) which naturally asserts a limit on throughput.
> ...
> Some resource limitation is definitely necessary, and supported by both
> TaskManager and ThreadPoolExecutor. In either implementation one can say
> "Use no more than 30 threads for this purpose.".
> That makes sense to me. Running too many threads increases resource
> utilization without increasing throughput. Even before that limit is
> reached, the need to share the system resources with other pools may
> limit the number of threads that can be allowed for one pool.
> The additional type of limitation that TaskManager supports and
> ThreadPoolExecutor does not is much weirder than that. TaskManager
> allows specification of a "load level" which is a ratio between the
> number of runnable tasks and the number of threads. For example, if the
> ratio is 3, then with 30 tasks it is limited to 10 threads. With 300
> tasks it is limited to 100 threads.
> If the system could efficiently accommodate 100 threads devoted to that
> pool, why not create 30 of them when there are 30 runnable tasks that
> could use them, rather than limiting the 30 tasks to 10 threads, keeping
> some of them waiting?

In a distributed system where users are just throwing requests into a system of 
"tasks", you can, as Dan says, have some admission control, because you no where 
the "non-system-dependency" control point is at.

When you are looking at the implementation of a distributed system, having 
"thread" controls or "resource limits" results in very difficult to understand 
failure modes.  Especially where there are no "timeouts" imposed or other "wait 
limits" available.  This is what I'm complaining about.  Let the designer of the 
system manage the "load" at the point of work insertion.  River's internals do 
nobody any favors by restricting "how many" or "when" things can happen.

If the system throughput is not meeting my needs, I'll apply admission controls, 
or "add hardware" to manage the issue.  Anything else done by river only serves 
as a "limit" that can be very frustrating to debug and deal with.

Gregg Wonderly

View raw message