[Dbbalancer-users] Re: [ dbbalancer-Bugs-477967 ] Configuration of backing off strategy

[Daniel V. S. <dv...@ar...>]

On Sun 04 Nov 2001 12:06, you wrote:

> At the moment DBBalancer appears to take a fairly
> simplistic approach to attempting to get a back-end
> connection when a client connects to it.
>

Yes, that's true. I first focused on make it somewhat "work". Now it's time 
to optimize both the code and strategies.

>
>
> In the event that all back-end connections are in use,
> it would be reasonable to put the request into a queue,
> holding it in abeyance for a [configurable] period of
> time before finally giving up and returning the
> connection failure to the client.

Well, I think that's what happens now, not at the connection level but at the 
thread pool level. Given that the thread number is equal to the connections 
number (which is the logical approach), if all the connections are busy is 
because all the threads are also busy. Then it is DBThreadPool who enqueues 
(via its activation_queue_ attribute) all new requests. Of course this 
doesn't work if there's a bigger number of threads than connections, but this 
situation should never happen unless configured so, because even the growing 
and shrinking of pools go synchronized (thread and conns at the same time and 
equivalent number).

Please tell me if you found a different behaviour, cos it surely could be a 
bug.

>
> With web applications this is especially useful because
> most connections are very short-lived (usually well
> under 1 second).  This would mean that a maximum queue
> wait time of (say) 700 - 1500 mS would allow a very
> busy system to gain considerable benefit in smoothing
> peak load.
>
>

What DBBalancer should also make better is the strategy to adaptively modify 
the number of threads and conns. Now it checks the average length of the 
latest 3 checks of the queue, but, while this avoids overreacting to fast 
bursts of requests, it's is quite slow on adapting.


>
> Hand in hand with this, it would be good to get
> statistics of connections handled / connections queued
> / connections dropped dumped to syslog every
> [configurable] seconds.  These statistics would enable
> the system admin to tune the numbers of client and
> server connections.

Some of these are already available. In fact, in DEBUG mode, DBThreadPool 
dumps the length and average (3 last checks) length of its queue. Anyway they 
should be augmented with more data, that's true.


>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=378947&aid=477967&group_id
>=23561

-- 

----------------------------------
Regards from Spain.  Daniel Varela
----------------------------------

If you think education is expensive, try ignorance.
           -Derek Bok (Former Harvard President)