The Ruby pool was originally made dynamic to deal with varying server
load: we didn't want a bunch of runtimes sitting around under light load
because they needed to be there to handle peak load. I'd imagine that
Grizzly has some pools lying around in it somewhere (like the
HttpWorkerThreads) that might want to change size based on load as well.
I'm not sure what the startup/memory usage of those threads are, though.
If they are cheap, then it's not as big a deal to keep a bunch of them
lying around idle. The Ruby runtimes were ~20MB of memory idle and ~5
seconds to start, so we wanted some intelligence behind starting them up
and taking them down.
In short: pools that experience significant changes in the amount of
load they are serving, where significant means that a noticeable amount
of resources are sitting idle maintaining the pool
The other possible place to use it is for automatic performance tuning,
since it will find the "right" number of objects in the pool fairly
quickly for constant load situations, which could then be used as the
values for a static pool.
John ROM wrote:
> [other stuff removed...]
> For me the main feature of the DynamicPool is the
> intelligently automatic judging when to increase and decrease the pool.
>
> Would anybody know of other usages beside "scripting runtimes" for using the
> dynamic pool?
>
> I am asking because then it might make sense to put it in framework module?
>
> Many Greetings
> John
>
>