Thats really an extensive explanation Thanks for writing this christopher Thanks, Vicky
On Oct 24, 2012, at 7:04 PM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Vicky, > > On 10/23/12 11:43 PM, vicky007aggar...@yahoo.co.in wrote: >> Andre & Christopher thanks a lot for your time & help. >> >> One last query related to mod _jk & mod_proxy_balancer modules:- >> among these two which one is preferred i mean which is more stable >> & has good performance.? Any idea >> >> It will be great if you can share document link which talks about >> there pros & cons > > I have been using mod_jk for a very long time and I saw (at the time) > only one reason to make the switch to mod_proxy_ajp: it is bundled > with Apache and so you (likely) don't have to build the module yourself. > > That said, simple configurations are *way* more simple in > mod_proxy_ajp than with mod_jk, although the (somewhat) recent > addition of JkWorkerProperty and JkMount "extensions" do help quite a bit. > > mod_proxy_ajp can also be trivially swapped-out with mod_proxy_http > just by changing the URLs in your ProxyPass and ProxyPassReverse > directives to say http:// (or https://) instead of ajp://. This might > help you if you need to switch protocols for debugging purposes or if > you suddenly need switch to HTTPS to secure the traffic without any > external configuration (e.g. stunnel or VPN). > > mod_proxy also supports ProxyPassMatch which lets you use regular > expressions in your URL mappings, which mod_jk's JkMount does not > (though you *can* use <LocationMatch> along with SetHandler in order > to achieve the same result, it's a cleaner configuration with mod_proxy). > > That said, I have found that mod_jk supports more complicated > configurations where I have struggled to get mod_proxy_ajp to do the > same. Specifically, overlapping URL spaces that must be mapped to > separate workers. Technically speaking, I suppose you could use lots > of ProxyPassMatch directives and/or have a complex regular expression > to direct the various URLs, but again you end up with a rather messy > configuration that way. Messy configurations are a maintenance risk as > well as at risk of becoming "arcane knowledge" that nobody actually > understands and so they are afraid to modify it for any reason. > > Generally, mod_jk will get fixed faster than mod_proxy_ajp due to its > independent release cycle: the httpd folks might have a fix for a > problem but it doesn't get released for a while due to testing of > other components, etc. At this point, mod_proxy_ajp has (IMHO) reached > a point of stability that this is less of an issue than it used to be. > > At this stage, there is no reason for me to move any of my projects > from mod_jk to mod_proxy_ajp but if I were starting from scratch, I > might choose mod_proxy_ajp solely due to its binary availability and > simple configuration. If the configuration became complicated to the > extent that switching to mod_jk were a good option, then I'd move. > > As for performance, I have no data on that one way or another. I would > suspect that mod_jk has a slight performance advantage because it has > been especially designed for the purpose rather than mod_proxy_ajp > which must support the mod_proxy API and might have a bit more > plumbing code to accomplish that. I would be surprised if you could > detect any performance difference between the two if you were to test > them both faithfully and with compatible configurations. If anyone has > relative performance data between mod_jk and mod_proxy_ajp, I'd be > happy to read it. > > Hope that helps, > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlCH7nUACgkQ9CaO5/Lv0PA4tQCfRMxpTCX2Q1QVeKC0DhU0QaWQ > unIAoINjyEaPMlFEVsXOFIOtXHIX+oZD > =DXAt > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
