8 posts categorized "mod_proxy"

07/24/2008

mod_jk vs. mod_proxy - connectivity options

It seems that based on the data from my server logs, "mod_jk vs. mod_proxy" is a popular search topic. Since all my visitors are shy and don't comment, I'm not sure if the introductory post on this topic I published a few months ago really provides any help on this. Therefore, I think a few more posts to flesh out the topic further might be in order. In this part, I'll describe some of the upstream connectivity options you get with mod_jk and mod_proxy to help you decide whether one is preferable over the other.

First off, these posts assume that you are using apache 2.2 and preferably apache 2.2.9, since this release fixed a lot of mod_proxy-related problems, If I remember correctly, I think that apache 2.2 was the first release that stated that mod_proxy was now considered ready for production deployments.

mod_jk only has one kind of connectivity protocol option, which is ajp. ajp is a binary protocol and ajp connections are very fast. If your back end/upstream application server does not provide an ajp/jk connector (like tomcat, jboss, jetty, and glassfish do), then you are not going to get much use out of mod_jk.

mod_proxy, on the other hand, has four different types of connection options, plus a fifth option that allows you to set up load-balanced clusters of nodes. There is a connector for ftp, one for http, one for ajp, and one for when your backend system is an ssl encrypted (https) session. So, if your backend application server does not support jk connections, you can use mod_proxy_http. Both mod_proxy-balancer and mod_proxy_ajp are new to apache 2.2

The one most prevalent in use by me right now is mod_jk. That's because mod_jk is very well documented and because I have a bunch of apache 2.0-based sites. I've been experimenting with mod_proxy_balancer load-balancing but I personally don't find it to be all that well documented yet. For example, setting up a mod_proxy_balancer configuration that utilizes ajp to connect to backend systems that support it is rather difficult and confusing in relation to setting up mod_jk to do the same thing.

That being said, http is more than likely going to be much faster than ajp with tomcat 6 and jetty (and due to the relationship between these and the open source application servers jboss, glassfish, geronimo, etc), mod_proxy_balancer over mod_proxy_http seems to be the configuration that will result in the best performance. This is due to the phenomenal performance improvements to the http connectors within these containers. As an added bonus with this configuration, the systems administrator gains the ability to run a network trace live during a problem and get a readable trace, which you won't get with an ajp connection. Apache routing traffic through mod_proxy_balancer to http application server backends will be my configuration of choice moving forward and as the older sites are upgraded, I will be looking to migrate them to this configuration as well--with the usual caveat being if a particular web application is making use of something like replication domains or something cool like that.

03/21/2008

mod_jk vs. mod_proxy - Introduction

With apache 2.2, things had become a little confusing (for me at least). I am not a member of the ASF, not a developer or tester on any of these projects, and I don't monitor development discussions. When I learned that apache 2.2 came out with a very full-featured "competitor" to mod_jk in the form of mod_proxy_balancer, the first question I asked myself was, "What was wrong with mod_jk?" I've been doing some research and to try and keep each post as brief as possible, I will probably need to break things up across multiple posts. As I'm writing this in my head, I've already thought of related articles that could be (and were) written like "Why front-end a tomcat box with apache any way?"

The other confusing thing to some about mod_jk is jk2. jk2 is deprecated but still around and some folks think that because it's jk2, it must be better and should be used over jk, which is not the case.

Finally, you need to be cognizant about the type of back-end application server you are connecting to. If the container is tomcat, glassfish, or jetty or based upon tomcat or jetty, then you can utilize mod_jk but if your upstream application server does not support ajp (apache jserv protocol), then mod_jk is not going to be very useful. One example of an application server where usage of mod_jk would not be appropriate is the websphere application server. Another is the pramati appliction server. I am not sure about Glassfish because I have never used it.

mod_proxy is a set of modules provided by the apache httpd project. mod_proxy, mod_proxy_balancer, mod_proxy_http, and mod_proxy_ajp provides everything you need to implement apache as a reverse proxy and provides for upstream application server connectivity. mod_proxy has been around for a while as well although mod_proxy_ajp and mod_proxy_balancer are fairly new but still well-tested. mod_proxy_ajp implements support for the ajp13 protocol and just about everything you can do with mod_jk can be done through mod_proxy_ajp. mod_proxy_http is a bit more universal because it speaks http everywhere.

I'm beginning to favor the mod_proxy_http approach for everything now mostly because of maintainability. With mod_jk, upstream workers are normally (although not necessarily) defined in a separate file. Upstream uri maps are implemented in still another file. mod_jk updates are implemented out-of-band from tomcat updates and from apache httpd updates. None of this is causing a particular hardship on me but it is just easier to tell someone that everything they need is in one configuration file. When I tell people that we load-balance with BigIP, mod_jk, or mod_proxy_ajp or mod_proxy_http, they just get confused. Cutting from 4 to 2 makes the suits feel better because they feel they can wrap their heads around 2 solutions over 4.

--Update--May 20th 2009--
One disadvantage to a mod_proxy based solution is that it is tied to apache releases. The last release of apache 2.2 was 2.2.11, released in December 2008. As of today, (May 20th, 2009), that's 5 months without an update to mod_proxy. Over this same time frame, there have been about three releases to mod_jk.