What are the pros and cons of using HTTP for web server communication with app server(s)

httpreverse-proxy

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?

Best Answer

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.