Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm primarily a Java developer, and I come to you with a question that straddles the divide between developers and sysadmins.

Years ago, when it was a novel thing to run Tomcat as an app server, it was customary to front it with Apache. As I understand it, this was done because:

  1. Java was considered "slow", and it was helpful to have Apache serve static content directly.
  2. Tomcat couldn't listen to ports 80/443 unless run as root, which was dangerous.

Java is no longer considered slow, and I doubt adding Apache to the mix will actually help speed things up.

As for the ports issue, there are probably simpler ways to connect app servers to ports 80/443 these days.

So my question is- is there really any benefit to fronting Java Webapps with Apache these days? If so, is Apache still the way to go? Should I look at Nginx? Instead of Tomcat I'm using Glassfish, if that matters.

share|improve this question

5 Answers 5

up vote 5 down vote accepted

Most people are going to say you need something in-front because of static files.

This is somewhat dumb because:

  • You can configure Tomcat to use the same IO as apache with APR
  • You should be using a CDN (Content delivery network) anyways.

The real reason you need something in-front of tomcat/jetty/jboss to load balance and handle failover.

I recommend you do not listen to "...The Tomcat engine is the Achilles heel of the entire ecosphere..." as we all know that is not true... your database and its connection pooling will be that.

share|improve this answer
    
Adam, are you stalking me from StackOverflow over to Serverfault? :-) I agree with your response. In retrospect, I should have worded the question better to reflect the real situation: there's really very little static content to speak of, since the DB is involved in almost any page hit. At this time (very early startup exploration) we don't need load-balancing, but with luck we will need it in the future. –  Caffeine Coma Feb 22 '11 at 14:16
    
@Caffeine Coma I'm in the same boat and it seems we are using the same technology hence the serendipity of being on the same threads across Stackexchanges (I swear I'm not stalking :) ). BTW we are using Nginx + Tomcat. –  Adam Gent Feb 22 '11 at 15:12

It depends on the ecosystem around your app. In an intranet environment - you probably do not need anything in front of Tomcat.

If alone on the internet as a public facing service, it depends. Apache is nice to because of the modules it provides like mod_security. But if you are not knowledgeable with the configuration of apache(or ngix) - then you could expose yourself to even MORE attacks or points of failure due to misconfiguration.

Apache in front comes in handy for serving outage pages in cases where you need to upgrade the webapp and wait for a restart. But if the restarts are rare or they are timed correctly - then its another reason to go Tomcat standalone.

The Tomcat FAQ does also talk about this too which addresses some additional points: http://wiki.apache.org/tomcat/FAQ/Connectors#Q3

share|improve this answer

Apache is not a good candidate to serve static content due to its multi-process nature. Nginx suits better since it uses asynchronous I/O to process requests. Modern Tomcats can use asynchronous I/O (NIO in Java terminology) too. For example, you should install tomcat-native package in Fedora to make Tomcat use async I/O.

share|improve this answer
    
I'm not really serving much static content anyway. My question is really: do I need to bother with an Apache/Nginx front-end, or just go with straight Glassfish? Thanks. –  Caffeine Coma Feb 3 '11 at 16:32
    
Actually, the problem is broader than just serving static content because if your server does not use async I/O clients with slow connections will block server's execution threads until they got the content in full. So, having an AIO-powered frontend is a benefit in any case. But, as I already mentioned, Tomcat has AIO capabilities. I think stock Glassfish package already includes AIO library, so you probably should not bother. –  Alex Feb 3 '11 at 16:50
    
apache isn't necessarily multi-process. mpm worker has been out for some time httpd.apache.org/docs/2.2/mod/worker.html and we're using in a production environment for a multi-threaded web server. –  dialt0ne Feb 3 '11 at 16:55
    
Well, multithreaded Apache still uses synchronous I/O. I don't see big difference if threads not processes will be blocked on a socket by slow clients. Nginx is designed as single-threaded single-process finite state machine (well, not necessary single-process, number of processes should be set to number of CPU cores on a multi-core system). –  Alex Feb 3 '11 at 17:04

Amazing, some of these answers - do any of you folks actually run high performance multi-tiered and mutli-server Tomcat backed websites? OP, your original supposition that Tomcat is not "slow"... wow. The Tomcat engine is the Achilles heel of the entire ecosphere.

Yes, you want Apache in front - it provides first and foremost mod_rewrite (have you already implemented UrlRewriteFilter in your Tomcat?) as well as the htaccess files that make protecting a webserver so important. Apache can enable you to load balance Tomcat nodes behind it, serve your static content much quicker and get better performance out of Tomcat because you're not overloading it's request pipe with non-Java (js/css/html/jpg/etc.) things. You can offload your SSL at Apache (if not offloading at a hardware LB) with ease and not even have to deal with that travesty called the Java Keystore. There are just so many wins - you can tune mod_jk to your backend nodes to keep from overrunning Java's poor little brain because it typically can't handle massive traffic with the average Java coder's classes.

Beware anyone who tells you that Apache (or nginx, etc - but Apache's performance will outshine Tomcat anyways so it doesn't matter) is not a good idea in front of Tomcat.

share|improve this answer
3  
You sound very offended. –  Caffeine Coma Feb 7 '11 at 4:09
    
Just disgusted that people offer such bad advice on ServerFault. –  troyengel Feb 7 '11 at 14:46
    
Beware anyone who rants with out any numbers to back such claims. If your site is mostly dynamic then direct tomcat is going to be faster. Most heavy traffic sites these days use CDN (content delivery network) for their static content so there is no reason to use Apache to serve your static content. That being said you should still have something infront for load balancing/ssl. –  Adam Gent Feb 21 '11 at 16:56

If it's just a matter of binding privileges port without being root when using Tomcat, you don't need to front it with Apache httpd. Tomcat by default ships with jsvc that you need to compile.

jsvc is a java service wrapper to launch Tomcat as a service. This service starts as root but start Tomcat as a normal user. So you can bind your Tomcat to privileged ports.

I don't know about Glassfish, but be sure that solutions exists and if not you can surely use port forwarding techniques (iptables, etc...)

I think the choice of fronting an application server with a web server (Apache httpd for instance) is for load balancing, clustering or serve static resources only with a web server and dynamic resources with an application server.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.