Re: [Dbbalancer-users] Re: about DBbalancer

[Andrew M. <an...@ca...>]

On Wed, 2002-02-06 at 21:06, Daniel Varela Santoalla wrote:
> Yes please. Tell me how you see that facility, in the full detail you have 
> thought it. This would definitely make DBBalancer more responsive to variable 
> load peaks....

OK, here is my thinking on this subject.  Obviously all up for
discussion and dissection.  Does anyone else have any ideas along these
lines?



On Connection
=============

DBBalancer would respond to a connection attempt by:
(a) looking in the pool for a currently inactive connection (as
current).
(b) waiting a short time in case a new connection becomes active.
(c) starting a new connection to the database.

The point behind stage (b) is that when we get a storm of connection
requests we back off in a structured manner.  The time delay here would
start at (say) 10mS, and would (say) double if we have started a new
connection in the last (say) 500mS.

In the initial implementation I would expect these three parameters to
be configurable to enable us to come up with appropriate defaults.

A further few parameters would be needed to control the initial pool
size, the maximum pool size and the maximum wait.  Even when the pool is
at maximum size DBBalancer should still wait up to the maximum wait
before returning a connection failure.

Apache also tracks load to some extent by starting new back ends to be
ready for incoming connections.  This is specified with a 'minimum spare
servers' parameter and I think that DBBalancer would benefit from this
approach also.


Connection Reaping
==================

Periodically DBBalancer should reap some inactive connections.  This
serves two purposes:
(a) Reduce the memory load when we are not serving a peak.
(b) Reduce exposure to memory leak problems in database client
processes.

Apache uses a given client for a <configurable> number of times, and
this seems a good strategy to emulate.  I would also add some sort of
parameter which specified the maximum duration that a connection should
be active for.  When a connection has serviced more than <n> requests,
or been in the pool for longer than <m> seconds (and is inactive, of
course) it would be reaped.

Similarly to the 'minimum spare servers', Apache implements a 'maximum
spare servers' and will reap the longest running servers when demand
falls so that there is more than this number of unused connections in
the pool.  I think DBBalancer should look to having this available as
well.  Measurement of the 'use' or otherwise of a connection would be
over a period of time, such as the last 60 seconds, possibly also
configurable in earlier releases.


Rationale
=========

Firstly, we want to try as hard as possible to give a requesting process
a connection, rather than a failure.

Secondly, starting a new connection is a reasonably high-overhead
process so if one is demanded we should try and put it off slightly as a
heuristic.  This situation will only happen when we are experiencing a
sudden load growth, so we want to be cautious about over-responding.

Finally, when the load drops away from a peak we want to leave the
machine more available for other maintenance tasks that might occur
during the quieter periods.  We still want to be ready to climb back
into it if needed though.


Regards,
					Andrew.

-- 
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/        PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201    MOB: +64(21)635-694    OFFICE: +64(4)499-2267
       Are you enrolled at http://schoolreunions.co.nz/ yet?