Re: [Dbbalancer-users] Re: about DBbalancer

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

Hello Andrew

The main difference that I see between this and the current strategy is about 
the "synchronicity" of making new connections. In your proposal, is the 
request thread who creates new connections when needed, depending on how long 
its current wait is. This would be "synchronous" to the requests. So far, 
this operation is done by a general thread, who grows or shrinks depending on 
the average queue size, "asynchronously" to the requests.

For implementing your proposal, further changes would be needed. I'll explain:
 Currently, the daemon always has (SHOULD HAVE) the same number of threads 
than of connections. This way, we are sure that every thread has an available 
connection whenever they ask for one. If the connection pool grows, also does 
the thread pool, and the same for shrinks. So it should be imposible to reach 
a situation in which a request being processed (and hence assigned to a 
thread) couldn't find its correspondent connection to use. A possible case 
would be when a host of a balancing pool failed, but not in "normal" use. 
Anyway, for this case it could be useful to introduce "growing" delays, as 
you proposed, between the different runs of tests for a connection, saving 
the case when threads temporaryly outnumber the "valid" connections available.

With this pattern a "processing" request never has to wait, and hence would 
never have an opportunity to create a new connection. So, where do "excess" 
request go? Well, they are kept in the thread pool queue, not being 
"processed" till they not have a thread (and a connection) free for them. 
That's why the growing and shrinking is done "asynchronously" by a "manager" 
thread, checking the queue size. It's important to note that growing the 
connection number WITHOUT growing the thread number is no use, as the new 
connections will never be assigned concurrently. This adaptive behaviour is 
driven by the queue size, which depends on the number of threads, not on the 
number of connections.

I think that a way to proceed is to define a Plan. First, defining goals, 
then defining ways to test them, and finally a strategy to get the goals. As 
you already pointed, the goals could be (I copy from your Rationale):

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

Never fail, OK

>
> 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.

Be cautious with grows, OK

>
> 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.
>

And be sure to free resources when no needed, OK.

I plan to create a test script wich does some connections, then many 
concurrent connections, then some serialized connections, then concurrent 
again, etc, so that we could:
a) Test correct handling
b) Test performance.

And the strategy could be the current, modified, or any other. But take in 
consideration that while Apache only pools one kind of resource (processes), 
we pool two different (threads and connections).

Please tell me what you think about all this.

Best Regards
Daniel.


>

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

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