Re: Busyness Method and others...
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 (what is used to monitor the health/load of nodes) technically by the methods please? Thanks and Best Regards Mohan 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...-tp14690721p14712091.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]
Re: Busyness Method and others...
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
Re: Busyness Method and others...
-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]
Busyness Method and others...
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 ? 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 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 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. Is this summary of mod_jk in non-technical perspective accurate ?? Thanks Regards Mohan -- View this message in context: http://www.nabble.com/Busyness-Method-and-others...-tp14690721p14690721.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]
Re: Busyness Method and others...
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]
