Take the 2-minute tour ×

Background: I want to separate our web server/app server functions onto separate machines (logically or physically). Meaning, I want to dedicate certain resources to serving static content (static HTML, images, Javascript, CSS, videos, etc...) and want to dedicate other resources to generating dynamic HTML (my web app, which happens to be a ColdFusion app and you may consider to be any J2EE app).

I'm familiar with several J2EE vendors methods for connecting their app servers with web servers. For instance, Adobe provides mod_jrun, Tomcat offers mod_ajp, mod_proxy_ajp, & mod_jk, Caucho (Resin) offers mod_caucho, etc... Several of these connectors allow for load balancing functionality. I guess they are communicating with a part of the app server that can function as a cluster controller.

One thing I've noticed is that these connectors are made for use with Apache (and often IIS on Windows). We are considering moving away from Apache to one of the lighter webservers, like Nginx or Cherokee. If I do that, it appears that I won't have the option for using a connectors like I mentioned above. The consistent suggestion in documentation for these servers is to just configure their HTTP reverse proxy capability in order to connect them to your app server (via the app server's HTTP implementation).

I'm interested in your experience with the performance implications of HTTP vs. other protocols used in a connector like I mentioned above. I assumed that those other connectors would function at a much lower level and have higher performance as a result. They obviously can bring new "features" like exposing an app server's load balancing functionality as I mentioned above.

So what do you think? Is the simplicity & flexibility of HTTP for communicating between the web and app tiers more attractive than the additional features of a more customized connector? Are there other issues in planning a multi-tier architecture like this that I haven't considered?

share|improve this question
O'Reilly has a book out titled RESTful Web Services that deals with this topic. You can get enough of a preview on Google Books to see if it helps your situation any...books.google.com/… –  Joe Internet Feb 2 '10 at 15:40

2 Answers 2

up vote 2 down vote accepted

There are plenty of examples of HTTP reverse-proxying in big websites, so I'd say it has no problems in terms of performance, scaling or ease of administration.

Adding nginx or equivalent to do load-balancing in front of your current servers won't change much, and you'll be able to gradually replace apache+mod_whatever when it doesn't add value anymore.

share|improve this answer

Before you get too far, I have to admit that I have no real data to answer your question. I have done some relatively minor testing of mod_proxy_http versus mod_proxy_ajp, but the results were inconclusive.

My understanding is that mod_jk has been deprecated in favor of mod_proxy_ajp; also mod_jk is (in my experience) more difficult to configure.

The way mod_proxy_ajp and mod_jk communicate between the front-end web server and the application server is essentially a binary form of HTTP, which would ideally be faster for the web server and app server to both send and receive. For load balancing, the mod_proxy family uses mod_proxy_balancer, which works with mod_proxy_http or mod_proxy_ajp. The bottom line is that there is no feature difference between the two.

share|improve this answer

Your Answer


