On Fri, Aug 4, 2017 at 11:47 PM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> Hi Martin, > > Am 04.08.2017 um 10:53 schrieb Martin Knoblauch: > >> Hi, >> >> just need some clarification on the mod_jk load blanacing method "Next". >> The documentation states: >> >> "If method is set to N[ext] the balancer will again use the number of >> sessions to find the best worker. All remarks concerning the Session >> method >> apply as well. The difference to the Session method is how the session >> count is handled in the sliding time window. The Next method does not >> divide by 2, instead it subtracts the current minimum number. This should >> effectively result in a round-robin session balancing, thus the name Next. >> Under high load, the two session balancing methods will result in a >> similar >> distribution, but Next will be better if you need to distribute small >> numbers of sessions. " >> >> What exactly is the "current minimum number"? How is the minimum taken? >> From all workers in the balancer set, or only the ACTive ones? I know, I >> should look it up in the code :-) >> > > I looked up the code I wrote 6 years ago. > > First: when using the session base lb methods, mod_jk needs to estimate > session counts. No lb method of mod_jk contacts the backends to get real > data, instead mod_jk uses the request info it sees to estimate the backend > situation. > > For session based methods, mod_jk counts requests, that do not include a > session id assuming that those are exactly the ones that create new > sessions. Of course: > > a) a session id can be outdated, meaning mod_jk would not count the > request as session creating but in fact it would create a new one. One can > at least configure mod_jk to be aware of login pages which will always > create a new session (see http://tomcat.apache.org/conne > ctors-doc/reference/uriworkermap.html and http://tomcat.apache.org/conne > ctors-doc/reference/apache.html and there look for "sticky_ignore"). > > b) a request without a session ID might not actually create a session, > depending on app details. There are additional config options to teach > mod_jk which URIs do not create sessions (see > http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html and > http://tomcat.apache.org/connectors-doc/reference/apache.html and there > look for "stateless"). > > c) sessions time out in backends and users can log out. mod_jk does not > track that. One can remove the session cookie during the logout, so that > the "new" requests from that user will be counted by the mod_jk session > counter. > > Because of these problems I typically recommend to stick to the default lb > method (request counting, not session counting). But sometimes apps have > resource usage dominated by sessions and then a "session" based lb method > can help, especially if you find a configuration which keeps the effect of > a)-c) above small. > > Since all counting methods, not only session based ones, would count stuff > since the last restart of mod_jk, but the current backend load situation > depends much more on stuff that happened recently, we try to get rid of > past counts by reducing the counters regularly. By default this happens > once per minute and is done in a way that the counters are divided by 2 > once per minute. That way old counter increases contribute less and less to > the current counter value. For the session based method this would mean we > assume half of the counted sessions die after one minute, 50% of the rest > during the next minute etc. Note that the counters are integers, so e.g. a > counter value of 1 will after division by 2 result in a new value 0. Most > often that is no problem, because on a loaded system numbers are big and > rounding down doesn't change a lot. > > The next request without session id will be send to the worker with the > smallest such "session" counter. > > The "Next" message varies that procedure by not dividing by 2 every > minute, but instead subtracting the minimum value of the backend counters. > Assume after the first minute, your 4 backends have "session" counters 2, > 3, 3 and 2. Then the minimum is 2, so after the minute we correct the > values to 0, 1, 1 and 0. Then we add for the next minute new sessions to > that counter and again subtract the new minimum etc. > > When would that be helpful? It was for an application with really huge > sessions but small session numbers. There was a risk that if for a minute > only 0 or one sessions were created on the backends, after dividing by 2 > all workers were again 0. > > You can actually track the counters via the status worker, were they are > exposed as column "V" (load balancer value). > > Regards, > > Rainer > > Hi Rainer, thanks a lot for the comprehensive write-up. Very useful. Just it does not answer my question on which workers are considered when determining the "minimum number" :-) Will all workers be considered, or only those in ACT state? The reason why I am interested in the session based methods is exactely that the application has a relatively small number of "sessions", which tend to be heavy weight (memory, I/O and CPU). The request methods tend to not lead to a good distribution of load here. What I really would be interested in is a balancer method that actually looks at the worker backends themselves to determine the load and state they are in. And I did not find a lot (any) pointers. I imagine that this is a difficult issue that may lead to its own problems (bad latency, ...). Cheers Martin -- ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
