tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angus Mezick" <amez...@guidestar.org>
Subject RE: JK2 LB_FACTOR problem
Date Fri, 09 Apr 2004 16:17:28 GMT
Back to that march 1 post.

> 1. lb_value += lb_factor
Ok, I see this I think.  But this happens after step 2.

> 2. the highest lb_value gets server;
Am I reading this code wrong, or is it the LOWEST value that is getting
the server


    /** Get one worker that is ready
     */
    for( level=0; level<JK_LB_LEVELS; level++ ) {
        for(i = 0 ; i < lb->workerCnt[level] ; i++) {
            jk_worker_t *w=lb->workerTables[level][i];

            if( w->mbean->disabled ) continue;
            if( w->in_error_state ) continue;
            if( w->lb_disabled ) continue;

            if( rc==NULL ) {
                rc=w;
                currentLevel=level;
                lb_min=w->lb_value;
                continue;
            }
            
            if( w->lb_value < lb_min ) {
                lb_min = w->lb_value;
                rc = w;
                currentLevel=level;
            }
        }
> 3. if lb_value > 255 lb_value = 0;
This hunk of code reads to me like: if the lb_value of the winning
server >255 then reset the lb_value of ALL workers on the level to their
lb_factor. (not 0)

    if( rc->lb_value != 0 ) {
            int newValue=rc->lb_value + rc->lb_factor;
            
            if( newValue > 255 ) {
                rc->lb_value=rc->lb_factor;
                /* Roll over. This has 2 goals:
                   - avoid the lb factor becoming too big, and give a
chance to run to
                   workers that were in error state ( I think it's
cleaner than looking for "max" )
                   - the actual lb_value will be 1 byte. Even on the
craziest platform, that
                   will be an atomic write. We do a lot of operations on
lb_value in a MT environment,
                   and the chance of reading something inconsistent is
considerable. Since APR
                   will not support atomic - and adding a CS would cost
too much, this is actually
                   a good solution.

                   Note that lb_value is not used for anything critical
- just to balance the load,
                   the worst that may happen is having a worker stay
idle for 255 requests.
                */
                for(i = 0 ; i < lb->workerCnt[currentLevel] ; i++) {
                    jk_worker_t *w=lb->workerTables[currentLevel][i];
                    w->lb_value=w->lb_factor;
                }
            } else {
                rc->lb_value=newValue;
            }


> 
> default lb_factor is 1, the value of 2 is two times higher,
> so using 100 i not appropriate. Use the numbers up to 10.
> It will give you 90%-10% workload in favor with the one with 
> value of 10.
> The maximum meaningful factor is 25.
> 
> 1. lb_value += lb_factor
> 
> 2. the highest lb_value gets server;
> 
> 3. if lb_value > 255 lb_value = 0;
> 
> That's the algorithm.
> 
> Is it perfect?
> Probably it could be better.
The level parameter REALLY helps if you want a primary/secondary set of
servers.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message