Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

2006-06-21 Thread Mathieu CARBONNEAUX




like alteon load balancer from nortel... they provide health check for many protocole...for http is only simple get to backend... and on the backend you must provide a responde this check (ex:statics file)...you can define how many ping after how it consider the backend dead...and how many seconds between ping...From: Jim Jagielski [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:02:11 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODORuediger Pluem wrote:  +1. Just one thought: I think it would be useful to have this 'health check' approach somewhat generic so that we can implement the call to it inside mod_proxy and its connection pooling itself (e.g. with providers supplied by schema handlers / modules). For AJP this would be CPING/CPONG of course and mod_proxy itself could offer a generic TCP connection 'health check' provider that simply checks the status of a TCP connection as far as this is possible without reading or writing data. This would be a very generic provider. Other protocol handlers could define other (better) protocol specific providers and just plug them in. Agreed. Making a generic hearbeat interface that could vary dependingon the actual protocol would be v. cool. So for AJP, CPING/CPONG,for HTTP some sort of generic TRACE (or HEAD)...-- ===   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/	"If you can dodge a wrench, you can dodge a ball."


Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

2006-06-21 Thread Mathieu CARBONNEAUX




why not add proxy hook like scheme handler do to that ?From: Ruediger Pluem [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:04:55 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOOn 06/19/2006 10:23 PM, Mladen Turk wrote: Henri Gomez wrote:  Good to see that PING/PONG got such a good response here. When I added this to mod_jk it was just a quick way to detect hang JVMs but it seems to many on the TC-DEV not a very usefull feature :)  And may thanks for such a great idea Henri ;) Actually its a great way to detect all those busy/broken/hanged/disconnected servers.  I'm not sure how we could add that feature to the http/https protocol, the Rudiger suggested.To be honest I currently have no generic idea how to do this withoutsupport from the backend. My point was more about that I would loveto see this health check integrated into the generic code of mod_proxyand its connection pooling and let the protocol modules provide the codethat actually does the dirty work of the protocol specific aspects of such ahealth check. This would make it easy to add health checks for other protocols/ add better ones for protocols with existing ones. As said currently I wouldonly see two health check providers:- CPING/CPONG for AJP.- A generic TCP connection check.But this would be open to further bright ideas.RegardsRüdiger


Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

2006-06-21 Thread Mathieu CARBONNEAUX




you must have the possibility to add a wheight to each backend to moderate the load (like nortel alteon)... no?From: Mladen Turk [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Tue, 20 Jun 2006 09:02:44 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOHenri Gomez wrote: Important point in load balancing will be to collect CPU load (job load) from the remote. We often make the mistake to split requests between servers as if it cost the same CPU power (or cpu load) for each of them, but in Java / J2EE some requests could be more CPU/IO/DB consuming than others.Well, I'm not sure that having the CPU load would mean something.For example you might have P3/1GHz and P66/100GHz with thesame load (close to 80%), and that info in that case would beactually misleading. It might help only if your hardware topologyis exactly the same for all backend servers.The bussines method OTOH will favor the 100GHz box over 1GHz one,thus giving more sense. Even with the same hardware topology,it is presumable that the shorter reply timeout would mean lessCPU cycles used.Regards,Mladen.