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

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

Hello Andrew


> > Please tell me if you found a different behaviour, cos it surely could be
> > a bug.
>
> I tried setting:
>
> daemon.init-db-connections=1
> daemon.min-db-connections=1
> daemon.max-db-connections=1
>
> And connecting several times in quick succession.  I saw a lot more
> failures than I was hoping for.  Watching the process of finding a
> connection also appeared to have almost no wait:
>
...

> Conn 0, NConns 1.
>  (5126,  07:50:19.049346) Connection 0::0 is NOT free!!!.
> (5126,  07:50:19.049394) Pool 0 won't give us a connection (try 9)!!!
> (5126,  07:50:19.049445) Impossible to get a connection after 10
> tries!!!
> (5126,  07:50:19.049494) We have not been able to get a connection.
> Closing client connection.

Have you also set all the thread parameters to 1?. If you've got more threads 
than connections this is what you likely get. BTW, there is another bug if 
you set everything to 1 (the "manager" object consumes the only thread 
preventing any further request processing...., so better try 2 in threads and 
1 in connections). I did this with 10 simultaneous clients without any 
apparent problem (total serialization).

Well maybe the wait time should be increased, but this is a situation that we 
never should reach, with correct configuration.


>
> What I was expecting to see was that the connections were serialised, so
> that the time to respond should have increased to include the time to
> wait for previous connections to finish.

>
> So it looks like a bug...
>
> Ideally I would see the number of attempts and the first retry delay as
> configurable.  I would then multiply the retry wait by 1.5 for each
> subsequent retry.

This "retry" is currently being handled by the thread pool. In fact the 
enqueued request is handled exactly in the moment when a thread (and hence, a 
connection) is freed. No delay.


>
> > 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.
>
> Sounds like you are saying that it would not be a good idea to set:
>
> daemon.reaper-delay=60

Definitely NOT. ;-)

>
> I had assumed that this only applied to _reaping_, not starting up...

Yes, that's an example of BAD NAMING to a parameter. It should be called 
daemon.manager-delay, but as that functionality changed with time, a bad name 
remained. I'll change it as soon as we definitely set how the 
growing/reaping/checking will work.

>
> I think a straightforward approach would be to start connections
> immediately if you find none available but are below
> daemon.max-db-connections - this would make things responsive to a
> quickly ramping load.  I consider reaping those when they haven't been
> used as a _much_ lower priority, hence my setting of the reaper delay to
> a higher level.

That can be a good approach. But I would have to change some things, as 
currently I do request processing in an "async" way, not in a "sync" one. 
Maybe a different thread, more frecuent... I don't know

>
> It's not debugging information, it's management information, so I want
> to be able to accumulate it on a busy website over several days before
> (perhaps) turning it off.
>
> Naturally I _don't_ want to be logging every query during that time :-)

Yes. I'll have to recheck log message "criticity" (:-m.. does this word 
exist... ;-)).

Regards

>
> Cheers,
> 					Andrew.

-- 

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

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