tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: Question about new mod_jk jk_lb_worker.c
Date Sun, 14 Nov 2004 17:32:56 GMT
Rainer Jung wrote:
> Hi Mladen,
> 
> 0) Any ideas on rotating the mod_jk log file?
>

Implementing inside apache's error.log is
the only solution. But that'll have to wait
for 1.2.8.


> Are the mathematically
> foundations behind that simple algorithm described anywhere?
> 


The idea behind this scheduler is the following:

lbfactor is "how much we expect this worker to work", or "the worker's
work quota".

lbstatus is "how urgent this worker has to work to fulfill its quota
of work".

We distribute each worker's work quota to the worker, and then look
which of them needs to work most urgently (biggest lbstatus).  This
worker is then selected for work, and its lbstatus reduced by the
total work quota we distributed to all workers.  Thus the sum of all
lbstatus does not change.(*)

If some workers are disabled, the others will
still be scheduled correctly.

If a balancer is configured as follows:

worker     a    b    c    d
lbfactor  25   25   25   25
lbstatus   0    0    0    0

And b gets disabled, the following schedule is produced:

lbstatus -50    0   25   25
lbstatus -25    0  -25   50
lbstatus   0    0    0    0
(repeat)

That is it schedules: a c d a c d a c d ...

The following asymmetric configuration works as one would expect:

worker     a    b
lbfactor  70   30

lbstatus -30   30
lbstatus  40  -40
lbstatus  10  -10
lbstatus -20   20
lbstatus -50   50
lbstatus  20  -20
lbstatus -10   10
lbstatus -40   40
lbstatus  30  -30
lbasatus   0    0
(repeat)

That is after 10 schedules, the schedule repeats and 7 a are selected
with 3 b interspersed.


> 
>>>1) Limiting new application sessions if load is to high.
> 
> Of course the "best" observable value would be the number of requests
> belonging to the same webapp. So some possible enhancement would be to
> count only requests with a fix URL prefix (that's not contained in the
> patch).
>

Can you open a bugzilla report and enter those patches so they
don't get lost.
I very much like the idea and I have apache2 code for counting
busy workers:


int server_limit, thread_limit;
/* Get the number of busy workers from scoreboard */
static int jk_server_busy_workers()
{
     int i, j, res;
     int busy = 0;
     worker_score *ws_record;
     process_score *ps_record;

     if (!ap_exists_scoreboard_image()) {
         return 0;
     }
     for (i = 0; i < server_limit; ++i) {
         ps_record = ap_get_scoreboard_process(i);
         for (j = 0; j < thread_limit; ++j) {
             int indx = (i * thread_limit) + j;

             ws_record = ap_get_scoreboard_worker(i, j);
             res = ws_record->status;

             if (!ps_record->quiescing
                 && ps_record->pid) {
                 if (res == SERVER_READY &&
                     res != SERVER_DEAD &&
                     res != SERVER_STARTING &&
                     res != SERVER_IDLE_KILL)
                     busy++;
             }
         }
     }

     return busy;
}

inside jk_post_config
+    ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
+    ap_mpm_query(AP_MPMQ_HARD_LIMIT_DAEMONS, &server_limit);



>>>3) Idle connection disconnect
>>
>>Use worker mpm. We just can not make maintainer thread for
>>non-treaded mpm's like apache1.2 or prefork.
> 
> 
> I don't use a seperate thread. I implemented this feature for Apache 1.3.
> The principles are the following (and I can sent complete code if you are
> interested):
>

You are running that on unix or windows?



> a) In common/service.h in jk_worker define an additional JK_METHOD check
> to be implemented by the workers:
> 

Please, do another bugzilla entry for that.

http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%205
Component: Native:JK
Severity: Enhancement

> 
> Thank's for the discussion!!
>

Thank you!

Regards,
Mladen

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