-----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
