[pool] "Smart" (aka auto-configure) pools

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[pool] "Smart" (aka auto-configure) pools

Steve Siebert
First, Paul, nice presentation at ApacheCon =)

I came up after the discussion to mention a feature I added to my pool
implementation, wanted to record this here and get community thoughts.

What I have done for a customer (non-releasable, but I can re-implement much
cleaner) was essentially enable the pool to "track" its maintenance
operations over a 24-hour period (starting at 0000) to better "predict"
configuration changes that needed to take place.  This was helpful in our
dev-to-production deployments for configuration "burn-in"...we could have
guessed what the config for the pool should be...but this helped get it
right quickly.  We kept it running (intentionally) and detected trends over
the first week.  We then turned this feature off (via JMX) and pool could
then adjust itself based on it's learned data.  Admittedly, this was a
"crude" implementation that was used to improve performance due to our
predictable spikes....there is a lot more that could be done.

First question:  is this coming the community would like?

Second:  If it is desired, I implemented this by re-implementing the
evictor...Paul suggested this might also be a good fit for an "outside"
implementation (I can see this, as well)

Finally:  What features would you like to see?

Thoughts?

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [pool] "Smart" (aka auto-configure) pools

Steve Siebert

Not Paul, Phil. My bad!

S

On Nov 4, 2010, at 2:34 PM, Steven Siebert <[hidden email]> wrote:

> First, Paul, nice presentation at ApacheCon =)
>
> I came up after the discussion to mention a feature I added to my  
> pool implementation, wanted to record this here and get community  
> thoughts.
>
> What I have done for a customer (non-releasable, but I can re-
> implement much cleaner) was essentially enable the pool to "track"  
> its maintenance operations over a 24-hour period (starting at 0000)  
> to better "predict" configuration changes that needed to take  
> place.  This was helpful in our dev-to-production deployments for  
> configuration "burn-in"...we could have guessed what the config for  
> the pool should be...but this helped get it right quickly.  We kept  
> it running (intentionally) and detected trends over the first week.  
> We then turned this feature off (via JMX) and pool could then adjust  
> itself based on it's learned data.  Admittedly, this was a "crude"  
> implementation that was used to improve performance due to our  
> predictable spikes....there is a lot more that could be done.
>
> First question:  is this coming the community would like?
>
> Second:  If it is desired, I implemented this by re-implementing the  
> evictor...Paul suggested this might also be a good fit for an  
> "outside" implementation (I can see this, as well)
>
> Finally:  What features would you like to see?
>
> Thoughts?
>
> Steve
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] "Smart" (aka auto-configure) pools

Phil Steitz
On 11/4/10 3:18 PM, Steve wrote:
>
> Not Paul, Phil. My bad!

Hey, NP.  I have a brother named Paul and he is way smarter than me :)

>
> S
>
> On Nov 4, 2010, at 2:34 PM, Steven Siebert <[hidden email]> wrote:
>
>> First, Paul, nice presentation at ApacheCon =)
>>
>> I came up after the discussion to mention a feature I added to my
>> pool implementation, wanted to record this here and get community
>> thoughts.
>>
>> What I have done for a customer (non-releasable, but I can
>> re-implement much cleaner) was essentially enable the pool to
>> "track" its maintenance operations over a 24-hour period (starting
>> at 0000) to better "predict" configuration changes that needed to
>> take place. This was helpful in our dev-to-production deployments
>> for configuration "burn-in"...we could have guessed what the
>> config for the pool should be...but this helped get it right
>> quickly. We kept it running (intentionally) and detected trends
>> over the first week. We then turned this feature off (via JMX) and
>> pool could then adjust itself based on it's learned data.
>> Admittedly, this was a "crude" implementation that was used to
>> improve performance due to our predictable spikes....there is a
>> lot more that could be done.
>>
>> First question: is this coming the community would like?
>>
>> Second: If it is desired, I implemented this by re-implementing
>> the evictor...Paul suggested this might also be a good fit for an
>> "outside" implementation (I can see this, as well)

We have talked a little over the years about making the pool smarter
or in some sense "adaptive."  The crude capabilities available now
via the maintenance thread (aka "Evictor") and idle instance
settings could certainly be improved.  Have a look at the
ErodingObjectPool and others in PoolUtils for other ideas in this
direction.

The challenge with making a smart pool implementation is that it is
hard to define an algorithm that "does no harm" (i.e. always
actually improves performance) can be fully documented and is at
least tractable to document, maintain and support.  That does not
mean it is impossible and I am interested in having a look at your
ideas.

So we have something concrete to look at, why don't you create a
patch with the new pool extending GOP if that is convenient?

Thanks!

Phil

>>
>> Finally: What features would you like to see?
>>
>> Thoughts?
>>
>> Steve
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] "Smart" (aka auto-configure) pools

James Carman
On Fri, Nov 5, 2010 at 10:11 AM, Phil Steitz <[hidden email]> wrote:
>
> The challenge with making a smart pool implementation is that it is hard to
> define an algorithm that "does no harm" (i.e. always actually improves
> performance) can be fully documented and is at least tractable to document,
> maintain and support.  That does not mean it is impossible and I am
> interested in having a look at your ideas.
>

Why not set it up so that the algorithm could be "plugged in" instead
of trying to come up with the end-all be-all solution?  The trick is
to make sure you capture all the metrics necessary for the plugged in
strategy can make its decision(s).  Or, you could do it another way.
You could allow the implementation to track all of the stuff that it
needs on its own.  This way, you'd have to "publish" events for
interested parties to subscribe to (object borrowed, object returned,
object discarded, etc.)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] "Smart" (aka auto-configure) pools

Phil Steitz




On Nov 5, 2010, at 10:23 AM, James Carman <[hidden email]> wrote:

> On Fri, Nov 5, 2010 at 10:11 AM, Phil Steitz <[hidden email]> wrote:
>>
>> The challenge with making a smart pool implementation is that it is hard to
>> define an algorithm that "does no harm" (i.e. always actually improves
>> performance) can be fully documented and is at least tractable to document,
>> maintain and support.  That does not mean it is impossible and I am
>> interested in having a look at your ideas.
>>
>
> Why not set it up so that the algorithm could be "plugged in" instead
> of trying to come up with the end-all be-all solution?  

+1

> The trick is
> to make sure you capture all the metrics necessary for the plugged in
> strategy can make its decision(s).  Or, you could do it another way.
> You could allow the implementation to track all of the stuff that it
> needs on its own.  This way, you'd have to "publish" events for
> interested parties to subscribe to (object borrowed, object returned,
> object discarded, etc.)
>
+1 but it would probably be more convenient for users to be able to hitchhike on the maintenance thread as Steve suggests to actually kick off adjustments.  Also, not just the pool but also object factories will need to publish events.

We should probably take this discussion to the dev list at this point.

Phil

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [pool] "Smart" (aka auto-configure) pools

James Carman
On Fri, Nov 5, 2010 at 10:47 AM, Phil Steitz <[hidden email]> wrote:
>
> We should probably take this discussion to the dev list at this point.
>

+1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]