Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri Gomez wrote: Well you we always indicate some sort of CPU power for a remote (a sort of bogomips) and use this in computation. Why should the CPU power matter, what if the high power CPU is getting all the complex requests and the lower power CPU is ending up with simple request (static content). You are better implementing it in control packets over AJP that can advertise that hosts current willingness to take on new requests on a 32/64bit scale. Call this a flow control back pressure packet, a stateless beacon of information which may or may not be used by the client AJP. Then have a pluggable implementation at the server end of calculating that value and frequency for advertising it. All the apache LB has to do is work from that load calculation. All existing AJPs have to do is just ignore the packet. In the case of different horse power CPUs that factor is better fed into the server AJP algorithm by biasing the advertised willingness to take on new requests after a certain low level is reached. Only the server end of the AJP know the true request rate and how near that system is to breaking point. This scheme also works where apache may not see all the work the backend is doing, like if you have a different apache front end clusters linked to the same single backend cluster. Darryl
Re: mod_proxy_balancer/mod_proxy_ajp TODO
The TomcatoMips indicator was just something to tell that it's not the raw CPU power which is important, but the estimated LOAD capacity of an instance. Accounting informations should included average time to execute a request, number of thread in use (AJP/HTTP), estimated free memory... Just to be sure that when a tomcat (for example), is near overload, the next requests will be routed to another less loaded tomcat. 2006/6/22, Darryl Miles [EMAIL PROTECTED]: Henri Gomez wrote: Well you we always indicate some sort of CPU power for a remote (a sort of bogomips) and use this in computation. Why should the CPU power matter, what if the high power CPU is getting all the complex requests and the lower power CPU is ending up with simple request (static content). You are better implementing it in control packets over AJP that can advertise that hosts current willingness to take on new requests on a 32/64bit scale. Call this a flow control back pressure packet, a stateless beacon of information which may or may not be used by the client AJP. Then have a pluggable implementation at the server end of calculating that value and frequency for advertising it. All the apache LB has to do is work from that load calculation. All existing AJPs have to do is just ignore the packet. In the case of different horse power CPUs that factor is better fed into the server AJP algorithm by biasing the advertised willingness to take on new requests after a certain low level is reached. Only the server end of the AJP know the true request rate and how near that system is to breaking point. This scheme also works where apache may not see all the work the backend is doing, like if you have a different apache front end clusters linked to the same single backend cluster. Darryl
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri Gomez wrote: The TomcatoMips indicator was just something to tell that it's not the raw CPU power which is important, but the estimated LOAD capacity of an instance. But its still apache working out TomcatoMips. I think that approach is still flawed. I'm saying only the server end of the AJP knows the true situation. The current setup presumes that the running apache instance has all the facts necessary to determine balancing. When all it knows about is the work it has given the backend and the work rate its betting it back. I'm thinking both ends apache and tomcat should make load calculations based on that they know at hand. As far as I know there is no provision in the AJP to announce Willingness to serve. Both ends should feed their available information and configuration biases it into their respective algorithm and come out with a result that can be compared against each other. The worker would then announce as necessary (there maybe a minimum % change to damper information flap) down the connector the info to apache. There probably need to be a random magic number and wrapping sequence number in the packet to help the apache end spot obvious problems. This would allow kernel load avg/io load (and anything else) to be periodically taken into account at the tomcat end. It would be expected that each member of the backend tomcat cluster is using the same algorithm to announce willingness. Otherwise you get disparity when apache comes to make a decision. So I suppose its just the framework to allow an LB worker to announce its willingness to serve I am calling for here. Not any specific algorithm, that issue can be toyed with until the end of time. An initial implementation would need to experiment and work out: * How that willingess value impacts/biases the existing apache LB calculations. * Guidelines on how to configure algorithm at each end up based on known factors (like CPUs, average background workload, relative IO performance). I'm thinking with that you can hit the widest audience to make a usable default without giving much thought to configuration. The type of approach kernels make these days, you only have to tweak and think about configuration in extreme scenarios but for the most it works well out of the box. Darryl
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri Gomez wrote: The TomcatoMips indicator was just something to tell that it's not the raw CPU power which is important, but the estimated LOAD capacity of an instance. Accounting informations should included average time to execute a request, number of thread in use (AJP/HTTP), estimated free memory... Just to be sure that when a tomcat (for example), is near overload, the next requests will be routed to another less loaded tomcat. If you want such information I think Tomcat (or the backend server) has to provide it. Cheers Jean-Frederic 2006/6/22, Darryl Miles [EMAIL PROTECTED]: Henri Gomez wrote: Well you we always indicate some sort of CPU power for a remote (a sort of bogomips) and use this in computation. Why should the CPU power matter, what if the high power CPU is getting all the complex requests and the lower power CPU is ending up with simple request (static content). You are better implementing it in control packets over AJP that can advertise that hosts current willingness to take on new requests on a 32/64bit scale. Call this a flow control back pressure packet, a stateless beacon of information which may or may not be used by the client AJP. Then have a pluggable implementation at the server end of calculating that value and frequency for advertising it. All the apache LB has to do is work from that load calculation. All existing AJPs have to do is just ignore the packet. In the case of different horse power CPUs that factor is better fed into the server AJP algorithm by biasing the advertised willingness to take on new requests after a certain low level is reached. Only the server end of the AJP know the true request rate and how near that system is to breaking point. This scheme also works where apache may not see all the work the backend is doing, like if you have a different apache front end clusters linked to the same single backend cluster. Darryl
Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO
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
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
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.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri 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 the same load (close to 80%), and that info in that case would be actually misleading. It might help only if your hardware topology is 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 less CPU cycles used. Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
I have had a need for this functionality in one application or other for a while now and have been researching various means of acheiving it without actually coding.mod_backhand ( www.backhand.org) which seems to be an abandoned project was very promising a few years back.I think, section 3.3 of http://www.backhand.org/ApacheCon2001/US/backhand_course_notes.pdf was some attempt in the past in this direction.Just wanted to put in this casual note.Thanks for keeping up the good work folks - appreciate itCheenuOn 6/20/06, Mladen Turk [EMAIL PROTECTED] wrote: Henri 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 the same 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.
mod_proxy_balancer/mod_proxy_ajp TODO
Hi guys, I'm would like to give few notes on the things I'm currently working on, so that eventually no duplicate work is done if someone already have similar things on his drawing board. 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. 2. Hot standby support. Something we have recently added to the mod_jk that allows to have the 'hot-standby' backend node, that sits there and does nothing until all the other nodes fail. 3. CPING/CPONG support for the AJP protocol, for checking the status of the backend server prior of sending the data itself. Comments? Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Mladen Turk wrote: Hi guys, I'm would like to give few notes on the things I'm currently working on, so that eventually no duplicate work is done if someone already have similar things on his drawing board. 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. +1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend server)correlate with resource utilization on the backend server in any but the most contrived cases? 2. Hot standby support. Something we have recently added to the mod_jk that allows to have the 'hot-standby' backend node, that sits there and does nothing until all the other nodes fail. Nice. 3. CPING/CPONG support for the AJP protocol, for checking the status of the backend server prior of sending the data itself. Sounds good. Bill
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Bill Stoddard wrote: 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. +1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend server)correlate with resource utilization on the backend server in any but the most contrived cases? Well, this is the only way the balancer can deduct the load of the backend server. If the backend server is highly loaded or with lower performance hardware it response time will be lower compared to the other participants in the cluster, so it will get less load, and vice versa. Of course the ultimate thing would be to actually receive the feedback from the backend server about its actual CPU/memory utilization, but thats not protocol independent. Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Bill Stoddard wrote: 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. +1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend server)correlate with resource utilization on the backend server in any but the most contrived cases? Yes, the algorithm is the average over the predefined amount of time. Further more Rainer Jung (our newest Tomcat commiter) has done a great job by rewriting most of the lb algos to be less spiky, so I plan to port his work to mod_proxy_balancer. Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Mladen Turk wrote: Hi guys, I'm would like to give few notes on the things I'm currently working on, so that eventually no duplicate work is done if someone already have similar things on his drawing board. 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. If this maps what's currently been done in mod_jk, than a big +1. It's been on my todo but have simply not had the cycles to do. I liked the new busyness algo, but then there was a total rewrite (well, not total) of it all, most likely since mod_jk doesn't want to use providers, that makes all the lb determination by value... I was thinking about extended the LB structs to also include some sort of LB lbstatus calculation which meant another cool abstraction and making the whole make-lb-algos-independent closer to reality. 2. Hot standby support. Something we have recently added to the mod_jk that allows to have the 'hot-standby' backend node, that sits there and does nothing until all the other nodes fail. +1 3. CPING/CPONG support for the AJP protocol, for checking the status of the backend server prior of sending the data itself. This will be cool, but I don't think too easy. Still +1 for the effort :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Jim Jagielski wrote: If this maps what's currently been done in mod_jk, than a big +1. It's been on my todo but have simply not had the cycles to do. That is exactly the thing that I'm planing to do. During last year there was a lots of good stuff added to the mod_jk that have even force some of the users used to try to compile and use mod_jk with httpd 2.2. IMHO there is no reason why we could not port all that good stuff. It's on my TODO list, and I'm glad to hear that you guys have the same thoughts. Perhaps I could explain all that to the much wider audience in Austin this September ;) ? Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Mladen Turk wrote: Bill Stoddard wrote: 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. +1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend server)correlate with resource utilization on the backend server in any but the most contrived cases? Yes, the algorithm is the average over the predefined amount of time. Further more Rainer Jung (our newest Tomcat commiter) has done a great job by rewriting most of the lb algos to be less spiky, so I plan to port his work to mod_proxy_balancer. Ok Mladen, thanks for the info. If the algorithm can account for things like hung applications in the backend (which would cause the reply time to spike) and place different applications in different balancing pools to keep one bad application from causing all traffic to be routed away from an otherwise available server, then it begins to become a usable routing algorithm. What are some other ways to intuit backend server performance other than 'reply time'? Some thoughts... It would be pretty slick to drive code into mod_proxy (or mod_lb, whatever) which could cause the server to 'request' performance stats from a backend server; The backend server would have to recognize the 'request' for performance stats and be able to respond by either adding a HTTP 'performance stat' header to the response (e.g. X-Performance-Foo: bar) or encase the performance stat data in a multipart mime message along with the response data. The proxy could gather the performance stat data out of the X-Performance-Foo header (or strip out the performance part of the multi-part mime response) and use the performance stats any way it wanted. Yea, I know there are packages out there that use lan multicast to exchange data like this. Ok, now going completely over the top wouldn't it be nice if mod_proxy could request arbitrary meta data (not just performance data)to be collected from backend servers; the backend servers obviously need to be able to understand and decode requests. ARM sort of does this for things like response time of every piece of code in a transaction path. I am thinking even more general. =Any= piece of information available to the backend server could be consolidated in a mod_proxy instance and acted upon at the scope of an entire cluster. Think debug data, performance data, QoS data, at whatever granularity needed (application, server, cluster). Once mod_proxy has access to lots of interesting bits, it can be programmed to detect and respond to anomalous application behaviors (what's considered anomalous is tunable and maybe is dynamically adjustable). Maybe it autonomically collect problem determination data and send alerts to the sys admin when anomalies are detected or adjusts it's operating characteristics in whatever manner the admin decides is appropriate. Bill Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Bill Stoddard wrote: Mladen Turk wrote: Once mod_proxy has access to lots of interesting bits, it can be programmed to detect and respond to anomalous application behaviors Huh, the thing you are talking about is some sort of rule based engine. Without having a virtual file system underneath the httpd, I'm afraid something like that is impossible, or at least unefficient. Once when we'll have the entire connection pool mapped as a file system inside httpd we can do more sophisticated things with balancing. Last time I mentioned VFS, the goal was 3.0. I already have some code inside sourceforge for couple of years, and just waiting the 'need' for it :) Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Hi, sorry for breaking the mail threading, but I read this list offline before and just subscribed to it now. I would like to release mod_jk 1.2.16 soon, but as soon as that release looks good, I would be willing to help syncing features between mod_proxy_balancer/mod_proxy_ajp and mod_jk. Comments see inline. Mladen Turk wrote: Bill Stoddard wrote: 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. +1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend server)correlate with resource utilization on the backend server in any but the most contrived cases? Yes, the algorithm is the average over the predefined amount of time. Further more Rainer Jung (our newest Tomcat commiter) has done a great job by rewriting most of the lb algos to be less spiky, so I plan to port his work to mod_proxy_balancer. Thanks Mladen for giving credits to my patches. Still more to do. Concerning Busyness: This is an interesting strategy for load balancing, when parallelity is a critical ressource. I know cases, where people do huge downloads via tomcat and then it's interesting to balance the amount of parallel downloads. Ok Mladen, thanks for the info. If the algorithm can account for things like hung \ applications in the backend (which would cause the reply time to spike) and place \ different applications in different balancing pools to keep one bad application from \ causing all traffic to be routed away from an otherwise available server, then it \ begins to become a usable routing algorithm. You could either use Busyness as a strategy, or you can set reply_timeouts, so that an application getting very slow will put the worker into error state. Such a worker will only be retried once a minute. With the head code of mod_jk you can now define several workers for the same Tomcat target and still use stickyness (needed by most applications). E.g. each context could get its own balancer with it's own error states, load balancing etc. For this you need to use the new attribute jvm_route. Before, the name of the worker had to be equal to the jvmRoute attribute on the tomcat side to make stickyness work. What are some other ways to intuit backend server performance other than 'reply \ time'? Some thoughts... It would be pretty slick to drive code into mod_proxy (or \ mod_lb, whatever) which could cause the server to 'request' performance stats from a \ backend server; The backend server would have to recognize the 'request' for \ performance stats and be able to respond by either adding a HTTP 'performance stat' \ header to the response (e.g. X-Performance-Foo: bar) or encase the performance stat \ data in a multipart mime message along with the response data. The proxy could \ gather the performance stat data out of the X-Performance-Foo header (or strip out \ the performance part of the multi-part mime response) and use the performance stats \ any way it wanted. Yea, I know there are packages out there that use lan multicast \ to exchange data like this. Ok, now going completely over the top wouldn't it be nice if mod_proxy could \ request arbitrary meta data (not just performance data)to be collected from backend \ servers; the backend servers obviously need to be able to understand and decode \ requests. ARM sort of does this for things like response time of every piece of code \ in a transaction path. I am thinking even more general. =Any= piece of information \ available to the backend server could be consolidated in a mod_proxy instance and \ acted upon at the scope of an entire cluster. Think debug data, performance data, \ QoS data, at whatever granularity needed (application, server, cluster). Once mod_proxy has access to lots of interesting bits, it can be programmed to detect \ and respond to anomalous application behaviors (what's considered anomalous is \ tunable and maybe is dynamically adjustable). Maybe it autonomically collect problem \ determination data and send alerts to the sys admin when anomalies are detected or \ adjusts it's operating characteristics in whatever manner the admin decides is \ appropriate. It would be definitely great to establish a meta data communication channel between Apache and Tomcat. Two interesting use cases would be - load status - available contexts Especially the second thing would be great for automatically managing mod_jk routing information (JkMount). Bill Regards, Mladen. Rainer
Re: mod_proxy_balancer/mod_proxy_ajp TODO
On 06/19/2006 06:21 PM, Mladen Turk wrote: Hi guys, I'm would like to give few notes on the things I'm currently working on, so that eventually no duplicate work is done if someone already have similar things on his drawing board. 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. Sounds good. 2. Hot standby support. Something we have recently added to the mod_jk that allows to have the 'hot-standby' backend node, that sits there and does nothing until all the other nodes fail. +1 3. CPING/CPONG support for the AJP protocol, for checking the status of the backend server prior of sending the data itself. +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. Regards Rüdiger P.S: Are you in Dublin next week?
Re: mod_proxy_balancer/mod_proxy_ajp TODO
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 :) 2006/6/19, Ruediger Pluem [EMAIL PROTECTED]: On 06/19/2006 06:21 PM, Mladen Turk wrote: Hi guys, I'm would like to give few notes on the things I'm currently working on, so that eventually no duplicate work is done if someone already have similar things on his drawing board. 1. Additional by business load balancing method that will load balance on the actual load of the beckend servers. The servers that have shorter reply time will get more load. Sounds good. 2. Hot standby support. Something we have recently added to the mod_jk that allows to have the 'hot-standby' backend node, that sits there and does nothing until all the other nodes fail. +1 3. CPING/CPONG support for the AJP protocol, for checking the status of the backend server prior of sending the data itself. +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. Regards Rüdiger P.S: Are you in Dublin next week?
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Rainer Jung wrote: Hi, sorry for breaking the mail threading, but I read this list offline before and just subscribed to it now. I would like to release mod_jk 1.2.16 soon, but as soon as that release looks good, I would be willing to help syncing features between mod_proxy_balancer/mod_proxy_ajp and mod_jk. Perfect. After all you have created most of the stuff, so you are more then a welcome :) Cheers, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
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. Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
2006/6/19, Mladen Turk [EMAIL PROTECTED]: 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. Well it's not easy to add this to http since HTTP stack could be consuming but you could imagine some sort of magic URI handled quickly by remote Tomcat (at the connector http/ajp side), and have some sort of timeout associated to this request. For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP...
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... Something like that was suggested by Jim Jagielski more then a year ago. I think that the problem is that this would be a module of a module, and something like that was never done for httpd. Not even sure if its possible. Regards, Mladen.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... A pluggable balancing strategy sounds nice. What I'm not sure about, if the size of problem is big enough to justify the work. All three existing strategies at the moment are based on the same basic principles. All strategies use the same unsigned 64Bit to describe the actual load value and there are three possible places where the values are adjusted: pre request, post request and during maintenance (called in regular intervals). Busyness: increment pre request, decrement post request, no op during maintenance Traffic and Requests: increment pre request, no op post request, decay during maintenance. Traffic and Requests use different values to increment, Traffic uses the amount of bytes transmitted, Requests always increments by one. So to be able to implement interesting balancing strategies, the plugins would need to be able to use request/response data, like performance, load, error status etc.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
On 06/19/2006 10:37 PM, Mladen Turk wrote: Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... Something like that was suggested by Jim Jagielski more then a year ago. I think that the problem is that this would be a module of a module, and something like that was never done for httpd. Not even sure if its possible. Isn't this already the case right now? AFAIK the current lb algorithms are provider based. So you can plug them in. From my understanding you can add further algorithms either to mod_proxy_balancer or you can put them in an separate module that registers them separately. Regards Rüdiger
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Rainer Jung wrote: A pluggable balancing strategy sounds nice. What I'm not sure about, if the size of problem is big enough to justify the work. A lot of it already exists already. That was my whole intent on the move to LB providers in proxy, and making such things as finding the best worker be external to the core code. The next step is to make the actual LB calc algo's also be such a provider, so that we can simply call calc_lbstatus and have that external as well :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Mladen Turk wrote: Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... Something like that was suggested by Jim Jagielski more then a year ago. I think that the problem is that this would be a module of a module, and something like that was never done for httpd. Not even sure if its possible. Actually, the current balancer does provide that, ala DAV and cache. The actual find best setup allows for submodules to implement them. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Ruediger 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 depending on 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: mod_proxy_balancer/mod_proxy_ajp TODO
Mladen Turk wrote: Jim Jagielski wrote: If this maps what's currently been done in mod_jk, than a big +1. It's been on my todo but have simply not had the cycles to do. That is exactly the thing that I'm planing to do. During last year there was a lots of good stuff added to the mod_jk that have even force some of the users used to try to compile and use mod_jk with httpd 2.2. IMHO there is no reason why we could not port all that good stuff. It's on my TODO list, and I'm glad to hear that you guys have the same thoughts. Perhaps I could explain all that to the much wider audience in Austin this September ;) ? ++1 ;) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
On 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 without support from the backend. My point was more about that I would love to see this health check integrated into the generic code of mod_proxy and its connection pooling and let the protocol modules provide the code that actually does the dirty work of the protocol specific aspects of such a health 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 would only see two health check providers: - CPING/CPONG for AJP. - A generic TCP connection check. But this would be open to further bright ideas. Regards Rüdiger
Re: mod_proxy_balancer/mod_proxy_ajp TODO
Ruediger Pluem wrote: On 06/19/2006 10:37 PM, Mladen Turk wrote: Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... Something like that was suggested by Jim Jagielski more then a year ago. I think that the problem is that this would be a module of a module, and something like that was never done for httpd. Not even sure if its possible. Isn't this already the case right now? AFAIK the current lb algorithms are provider based. So you can plug them in. From my understanding you can add further algorithms either to mod_proxy_balancer or you can put them in an separate module that registers them separately. That's right. I used the DAV/cache scenario when designing the provider impl in the balancer. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: mod_proxy_balancer/mod_proxy_ajp TODO
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. 2006/6/19, Jim Jagielski [EMAIL PROTECTED]: Ruediger Pluem wrote: On 06/19/2006 10:37 PM, Mladen Turk wrote: Henri Gomez wrote: For the load-balancing algorythm, do you plan to propose a bunch of pre build algos and let users select the right one for their use or allow externals modules ? We could see that like mod_jk / mod_proxy modules like apache modules does for HTTP... Something like that was suggested by Jim Jagielski more then a year ago. I think that the problem is that this would be a module of a module, and something like that was never done for httpd. Not even sure if its possible. Isn't this already the case right now? AFAIK the current lb algorithms are provider based. So you can plug them in. From my understanding you can add further algorithms either to mod_proxy_balancer or you can put them in an separate module that registers them separately. That's right. I used the DAV/cache scenario when designing the provider impl in the balancer. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
