Great information. This was what we were looking for. This will help us a lot in future changes to our cluster and node infrastructure. Thank you very much. Regards Mohan
Rainer Jung-3 wrote: > > Mohan2005 wrote: >> Hello Rainer; >> >> Thanks again for taking the time and for the information. >> >> if I quote you >> " >> Who told you that? cping/cpong have nothing to do with load decisions. >> They only help in deciding, if a worker is in error status or not. Load >> is distributed between all nodes that are not in error. To which of >> those nodes a request goes is not decided by cping cpong. >> " >> >> >> But the million dollar question :-) is , if cping,cpong does not >> determine a >> nodes HEALTH OR LOAD as you put it, how is the LOAD on a node determined > > It *does* influence Health status, but not load status. > >> (what is used to monitor the health/load of nodes) technically by the > > Health: independant of method. Always: timeouts (if configured, > socket_timeout, cping/cpong=connect_timeout and prepost_timeout, > response time=reply_timeout, max_reply_timeouts, fail_on_status, > recovery_options, see > > http://tomcat.apache.org/connectors-doc/reference/workers.html > > For all healthy ones: if lb has sticky_sessions and there is a session > with a route coming with the request, do not balance but use the best > worker w.r.t the session (but only from the healthy ones): The result is > influenced by activation, the worker name, route, redirect, domain (and > I think distance). > > If sticky, but all allowed workers are not healthy and > sticky_session_force: error > > Else or if not sticky: pure balancing (between the healthy workers) > influenced by activation, and lb_factor. > > Balancing itself choses the worker with the lowest lb_value. How do we > get an lb_value. I cite myself: > > ======= > - method "Request" (default): increase the load value of a worker by one > for each request send to the worker and divide by two all load values > every now and then (app. once a minute). So the load value is the > comulative number of requests handled by the worker with a envelope > curve that counts older requests less than more recent ones. This method > tries to keep total work balanced. > > - method "Session": the same as Request, but do only count a request, if > it didn't contain a session cookie or URL encoded session. It is not the > same as actually knowing how many sessions each backend has. > > - method "Busyness": load value is the number of requests currently > being processed by a worker. For example when load is low, most or all > workers will have load value "0". This method tries to keep concurrency > balanced. It will not be good in balancing total work. > > ======= > > and finally (I forgot in the original mail) > > - method "Traffic": Like request, but for each request do not increment > by one, instead increment by the number of bytes transferred to the > backend for the request plus receuved from the backend with the response. > >> methods please? >> >> Thanks and Best Regards >> Mohan > > > Regards, > > Rainer > >> >> Rainer Jung-3 wrote: >>> Mohan2005 schrieb: >>>> Hello! >>>> >>>> The documentation says the following on the Busyness Method... >>>> >>>> QUOTE >>>> If set to B[usyness] the balancer will pick the worker with the lowest >>>> current load, based on how many requests the worker is currently >>>> serving. >>>> This number is divided by the workers lbfactor, and the lowest value >>>> (least >>>> busy) worker is picked. This method is especially interesting, if your >>>> request take a long time to process, like for a download application. >>>> END QUOTE >>>> >>>> What is defined as "take a long time", is it 30 sec, 40 sec, or more ? >>> Let us rephrase this. Busyness is especially useful, if the number of >>> parallel requests you can handle is your limiting factor. Suppose you >>> need to handle very high concurrency, like e.g. 10.000 parallel >>> requests. Then you might come close to how many connections your >>> components (OS, web server, Tomcat, etc.) can handle and you need to >>> balance with respect to the expensive ressource "connections" instead of >>> CPU etc. >>> >>> Now how does parallelity relate to long running requests? >>> >>> Parallelity = Throughput * ResponseTime >>> >>> So given some fixed throughput, parallelity grows proportional to >>> reponse times. Talking about long response times is thus a simplified >>> rephrasing of talking about high concurrency. >>> >>> If you have 10 request per second (not a high load), but the response >>> time is 5 minutes, then you will end up with about 3.000 parallel >>> requests and this could be a good scenario for busyness method. >>> >>>> and >>>> from the clarifications I have got from this forum, the nodes "load" is >>>> determined by it network latency using cping and cping. These I believe >>>> are >>> Who told you that? cping/cpong have nothing to do with load decisions. >>> They only help in deciding, if a worker is in error status or not. Load >>> is distributed between all nodes that are not in error. To which of >>> those nodes a request goes is not decided by cping cpong. >>> >>>> used by all load-balancer methods to determine a nodes health. So >>>> checking >>>> the Requested hits (Acc in jkmanager) or Busy (Busy in jkmanager) or >>>> the >>>> Traffic are just checking the counters of a node that is more active >>>> than >>>> the other nodes. >>>> >>>> Essentially what all these methods does is check a node's health by >>>> cping, >>>> cping (Network latency) , and if it responds in good time, then check >>>> either >>> yes >>> >>>> the 'Acc', 'Busy' or 'Traffic' counters and send to the node with least >>>> 'Acc' if 'Request' method is used or "Busy" if 'Busy' method is used or >>>> "Bytes IN/OUT" if "Traffic" method is used. >>> yes >>> >>>> Is this summary of mod_jk in non-technical perspective accurate ?? >>>> >>>> >>>> Thanks >>>> Regards >>>> Mohan >>> Regards, >>> >>> Rainer > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Busyness-Method-and-others...-tp14690721p14715235.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
