Using Tomcats(in an apache-tomcat cluster) as reverse-proxies to apache servers behind

I'm writing a small web service(like a content server) to search and serve content. Basically it has 2 parts - one dynamic part performing client authentication and providing search functionality over the content. The second part involves serving static content to the authenticated client.

What can be a good architecture for the above service in terms of performance and scalability?

1. Just using an application server(tomcat) to do both?
2. But then I hear apache is better at serving static content having easy configurable options like compressing content. So how about using Tomcat as reverse proxy(using j2ep, noodle..) to apache web servers behind. Tomcat can authenticate and search while the apache servers behind can serve the content.
3. But Tomcat being the single point of contact, can become a performance bottle neck. So why not use the apache tomcat clustering again to balance load on the entire set up?

Basically I'm looking at a apache-to开发者_运维百科mcat cluster where each tomcat acts as reverse proxy to a set of apache servers behind. Is this set up possible? Has anyone done this before? I did search on this but unable to find any pointers. If it is possible, are there any potential disadvantages in this architecture?

In case if it is a bad option, what would be the right way to go for this web service?

To start with I would use tomcat for both static and non static content. tomcat ( from version 5 AFAIK ) has done well in static content serving as well. But if this is not performing well for you then I suggest that you have Apache httpd as the frontending server and tomcat behind it. I have used mod_jk and the JKMount directive can tells apache what are calls to be forwarded to tomcat. So the stuff that doesnt match the JKMount directive are handled by Apache httpd itself. So your static content can be served by httpd and the non-static requests are directed to tomcat. You can have multiple tomcats depending on the load.

But you need to be careful as to how the static content request will be authenticated.

To be able to scale, introduce a level of indirection between the actual content and its access. Like a handle to a content which could be obtained from anywhere. So you could replicate your static content in many locations distributed geographically ( or use CDN )

Hope this helps a bit.