Why use Apache Web Server in front of Glassfish or Tomcat?

Is it good idea to use Apache Webserver in front of GF or Tomcat? Does it improve the performance/security?

Or there is not any reason to use Apache Web Server with GF?

Solution 1:

Taken from https://cwiki.apache.org/confluence/display/TOMCAT/Connectors#Connectors-Q3

• Clustering. By using Apache HTTP as a front end you can let Apache HTTP act as a front door to your content to multiple Apache Tomcat instances. If one of your Apache Tomcats fails, Apache HTTP ignores it and your Sysadmin can sleep through the night. This point could be ignored if you use a hardware loadbalancer and Apache Tomcat's clustering capabilities.
• Clustering/Security. You can also use Apache as a front door to different Apache Tomcats for different URL namespaces (/app1/, /app2/, /app3/, or virtual hosts). The Apache Tomcats can then be each in a protected area and from a security point of view, you only need to worry about the Apache HTTP server. Essentially, Apache becomes a smart proxy server.
• Security. This topic can sway one either way. Java has the security manager while Apache has a larger mindshare and more tricks with respect to security. I won't go into this in more detail, but let Google be your friend. Depending on your scenario, one might be better than the other. But also keep in mind, if you run Apache with Tomcat - you have two systems to defend, not one.
• Add-ons. Adding on CGI, perl, PHP is very natural to Apache. Its slower and more of a kludge for Tomcat. Apache HTTP also has hundreds of modules that can be plugged in at will. Apache Tomcat can have this ability, but the code hasn't been written yet.
• Decorators! With Apache HTTP in front of Apache Tomcat, you can perform any number of decorators that Apache Tomcat doesn't support or doesn't have the immediate code support. For example, mod_headers, mod_rewrite, and mod_alias could be written for Apache Tomcat, but why reinvent the wheel when Apache HTTP has done it so well?
• Speed. Apache HTTP is faster at serving static content than Apache Tomcat. But unless you have a high traffic site, this point is useless. But in some scenarios, Apache Tomcat can be faster than Apache httpd. So benchmark YOUR site. Apache Tomcat can perform at httpd speeds when using the proper connector (APR with sendFile enabled). Speed should not be considered a factor when choosing between Apache httpd and Tomcat
• Socket handling/system stability. Apache HTTP has better socket handling with respect to error conditions than Apache Tomcat. The main reason is Apache Tomcat must perform all its socket handling via the JVM which needs to be cross platform. The problem is socket optimization is a platform specific ordeal. Most of the time the java code is fine, but when you are also bombarded with dropped connections, invalid packets, invalid requests from invalid IP's, Apache HTTP does a better job at dropping these error conditions than JVM based program. (YMMV)

Solution 2:

Since everybody gave you reasons why to put Apache in front of Tomcat let me give you some reasons why not to:

• The AJP connector does not and will not support advanced IO meaning no Comet, Websockets, etc.
• If you're not using AJP I have noticed there is a pretty big proxy overhead when using mod_proxy for Apache. So if you're looking for low latency Apache in front would not be good.
• Apache has a rather big foot print compared to Nginx or Lighttpd etc.

Putting Apache in front does NOT:

• Improve performance. Tomcat will run just as fast as Apache (in some cases faster) with APR.
• Improve Security. I don't think I have ever seen a true security problem with Tomcat. I don't know where this BS comes from that Tomcat is less secure than Apache.

What Apache does give you is more plugins and allows you to run different web technologies.

If you only need Tomcat you would be better suited to use a HAProxy or Nginx as load balancer.

Solution 3:

• Scalability - As Amir and user384706 pointed out, you can load balance multiple instances of your application behind Apache. This will allow you to handle more volume, and increase stability in the event one of your instances goes down.

• Security - Apache, Tomcat, and Glassfish all support SSL, but if you decide to use Apache, most likely thats where you should configure it. If you want additional protection against attacks (DoS, XSS, SQL injection, etc.) you can install the mod_security web application firewall.

• Additional Features - Apache has a bunch of nice modules available for URL rewriting, interfacing with other programming languages, authentication, and a ton of other stuff.

• Performance - If you have a lot of static content, serving it with Apache will improve your performance. If most of your content is dynamic, using Tomcat or Glassfish alone will be just as fast (probably faster). _{(as pointed out by answers to this question, this isn't true any more.)}