Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We got this JavaEE WebApp (JSP+Struts+Hibernate+MySQL) which currently is running on a single server. Due to growth of the website and performance issues we've decided to cluster the project on some machines. The Web Site should tolerate something like 5000 requests per second. After some googling around and reading stuff I've come around some strategies to get this done:

  • Using Apache as a front-end Load Balancer and reverse proxy, some Tomcat Instances each one on a separated machine, and finally a DB Server running MySQL. Tomcat instances can scale in the time of need.
  • Using Nginx as a front-end Load Balancer and reverse proxy. The rest would be the same as above.
  • Using HAProxy as a front-end Load Balancer and reverse proxy. The rest would be the same as above.

I suppose in aforementioned approaches all the traffic should pass through the front-end load balancer (Apache, Nginx or HAProxy Server). this makes the front-end server a bottleneck and also a SPOF. Is that right? can a single front-end server tolerate all the traffic of a big webapp?

to come around this issue, I've come up with a kinda handmade strategy:

  • Putting the Login page and authenticating actions on a front-end server (for example it will be accessible from when a user logs in successfully, he is redirected to one of the backend servers (like and continues his activity there.

So, am I in the right path?

Let me know of your opinions on these approaches and if you are thinking of a better one please me by mentioning it here.

share|improve this question
up vote 4 down vote accepted

Putting the login page on a frontend server and redirecting to backends is a bad idea. Users might bookmark your backend servers, you might end up with uneven distribution and when a server goes down users will still be trying to hit it if they're on the same session.

What you need is an active/passive (Heartbeat/*Pacemaker*/IP-Failover/*DNS-Failover*) or active/active (DNS round-robin/*network load balancing*) frontend servers.

With active/passive all your traffic would be redirected to one frontend server, with a second standing by (hot standby). When the first one went down you would somehow failover (Ether by re-assigning the IP address or modifying the DNS*) to point to the second server.

With active/active you would have two (or more) servers constantly active, using ether DNS round robin or IP/network load balancing to distribute load (roughly) evenly between the two. Then the two servers would again distribute load to your backend servers.

active/active is the method used by most large web applications (Look at the DNS records of Youtube/Google/Twitter/ and they will have multiple IPs for the servers for DNS round robin.

Once you've made that decision and implemented it, all you have is a choice between solutions. Personally I'd suggest NGINX but everybody has their preference (HAProxy, Squid, Cherokee, Lightspeed, F5 (hardware), Cisco (hardware) and countless others).

Unfortunately, for this sort of question we can't just say "do this" because it really depends what your requirements are. Research some of the keywords above and if you have any specific questions feel free to ask.

*DNS based failover should probably be avoided if possible, some clients will cache DNS beyond it's TTL so it's less than ideal.

share|improve this answer
Comprehensive answer! you kinda shed the light on the problem. thanks. – SJ.Jafari Nov 29 '11 at 10:24

I don't know about nginx but you can pair a couple of haproxy load-balancers in an active/passive configuration to prevent haproxy from becoming that single point of failure.

There are also commercial solutions, too, but they do not seem get as much "ink" on serverfault for some reason.

share|improve this answer
Commercial solutions (usually) get as much ink as they deserve. For many situations an F/OSS solution works just as well as a commercial one, so it's very hard to recommend something that costs more when the benefits are going to be the same, generally speaking. Also, if you're associated in any way with a product you must disclose that fact; this requirement nips many well intentioned posters. – Chris S Nov 22 '11 at 13:55

Your Answer


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.