Hi Takayuki,
Thank you. I committed your suggested patch. It will be released with
version 1.2.20, which should be available for tests in a few days.
I added a couple of warnings to the documentation:
"Please note, that session stickyness and perfect load balancing are
conflicting targets, especially when the number
of sessions is small, or the usage of sessions is extremely varying
For huge numbers of sessions this usually is not a problem.
Because the balancer does not keep any state, it actually does not know
the number of sessions. Instead it counts each request without a session
cookie or URL encoding as a new session. This method will neither
know, when a session is being invalidated, nor will it correct its load
numbers according to session timeouts or worker failover. This method
should be used, if sessions are your limiting resource, e.g. when you
only have limited memory and your sessions need a lot of memory."
I would in general *not* recommend this method to evenly distribute
requests. Somehow I would still like to know, why the requests in your
case have not been distributed evenly with the Request method. Could it
be, that only few sessions were active, and your client programm didn't
have a high degree of parallelity, concerning the used sessions?
You might know, that mod_jk can now log additional load balancing
information in your apache access log, so that we get a better idea, how
the balancer made its decisions. To collect some more runtime
information, please add the following to your Apache LogFormat:
\"%{Set-Cookie}i\" \"%{Cookies}o\" %{JK_WORKER_NAME}n %{JK_WORKER_TYPE}n
%{JK_REQUEST_DURATION}n %{JK_LB_FIRST_NAME}n %{JK_LB_FIRST_VALUE}n
%{JK_LB_FIRST_ACCESSED}n %{JK_LB_FIRST_ERRORS}n %{JK_LB_FIRST_BUSY}n
%{JK_LB_FIRST_STATE}n %{JK_LB_LAST_NAME}n %{JK_LB_LAST_VALUE}n
%{JK_LB_LAST_ACCESSED}n %{JK_LB_LAST_ERRORS}n %{JK_LB_LAST_BUSY}n
%{JK_LB_LAST_STATE}n %D
The STATE fields will show, if during balancing errors occured, so that
mod_jk disabled a member worker. The VALUE field shows us the load
factor at the time the decision has been made. And the ACCESSED field is
the number of requests handled since last reload. FIRST differs from
LAST, in case the first chosen worker had a problem and the load
balancer needed to try other ones.
Regards,
Rainer
Takayuki Kaneko schrieb:
> Hi,
>
> I'm evaluating mod_jk1.2.19 with 8 Tomcat application servers.
> I found problems about loadbalancing method.
>
>
> * method=Request
>
> Suddenly, balancing wouldn't be equally.
> When the requests were concentrated a particular Tomcat server (e.g.
> tomcat1). It was caused by sticky session when a particular user
> accessed a lot, user accessed the page that contains a lot of images,
> and so on.
> After that, mod_jk concentrated the requests to other Tomcat servers.
> So tomcat1 would have idle time.
>
> Here is the data of CPU usage when I ran the test with 2 Tomcat servers.
> http://jbento.sourceforge.net/modjk/CLIENT_200.html
> Sometime, tomcat1 had high CPU usage, but tomcat2 had idle.
> They worked alternately.
>
>
> * method=Busyness
>
> Balancing cannot be equally when Apache has been restarted.
> Because mod_jk has the offset value that is used to set the start
> point of searching endpoints on each Apache process. So, each process
> selects a particular Tomcat server that is the top of the endpoint
> list.
>
> Here is the summary of jk-status report.
>
> Name V Acc Err
> kuma03 0 9075 0
> kuma04 0 10013 0
> kuma05 0 9199 0
> kuma06 0 8996 0
> kuma07 0 8914 0
> kuma08 0 7043 0
> kuma09 0 6234 0
> kuma10 0 5260 0
>
> kuma10 is the bottom of endpoint list and it didn't work so much.
>
> --
> So, in my opinion, lb_value should be counted up when the request
> doesn't have the sessionid. It is advisability because the sticky
> session causes the status concentrated.
>
> I made the patch to make the new method "Session".
> I run the tests and the requests were balanced equally.
>
> Thanks.
>
> -Takayuki
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
