HTTP Server Load Balancer

HTTP Server Load Balancer

Load Balancing is a basic technique for routing traffic, such as HTTP requests, to a server in a way that achieves optimal performance, high availability, or easier service implementation. Hardware Server Load Balancer can handle any (or most) TCP and UDP protocols, while an HTTP specific SLB would obviously only do HTTP and perhaps HTTPS. With an HTTP Server Load Balancer, you can:

• 
  Assure a particular user always hits the same backend (real-) server
  
• 
  Assure a particular URL is served by the same backend (real-) server
  
• 
  Assure there is always at least one real-server available to serve any type of request
  

Getting users, or requests, associated with a smaller number of servers can significantly improve the performance of your applications. You can see better cache affinity, smaller active data sets, and easier (and faster) code to evaluate.

The follow picture depicts a typical HTTP Server Load Balancer setup:

3. 
   Server Load Balancer
   

1. Using Apache TS As SLB

Unfortunately, this is an area where Traffic Server is currently behind the curve, and we openly admit it. Basic Load Balancing can be done with the configurations available, but anything advanced will require coding for a custom plugin. There is some hope that an additional piece of technology can be open-sourced, but there is no ETA at this time.

So why are we talking about this at all? Well, it is an important feature that is somewhat lacking in Apache Traffic Server, and our hope is that discussing this openly will attract attention and interest from other developers who would like to work on these features. Also, in all fairness, some of the other HTTP intermediaries do a great job here; we have much to learn from them.

8. Conclusions

Apache Traffic Server is one of several free HTTP intermediaries, which when properly used can improve scalability, availability and performance for many mission-critical services. We do not expect TS to be the optimal solution for every possible application, but we think it is a viable option for many common use cases.

We believe that Traffic Server provides a solution that is flexible, easy to setup, protocol conformant, and provides very high performance. In particular, Traffic Server:

• 
  Is (or will be) at least as fast as the existing alternatives
  
• 
  Scales well on modern SMP systems
  
• 
  Has a feature set that is on par with the best intermediaries
  

As the community grows and matures, the hope is that Traffic Server will catch up where it is missing functionality or features. Performance-wise, we believe it already delivers an outstanding result.

The Apache Traffic Server mailing lists[1] and IRC chat rooms are a great place to get started. Please come to ask questions or to provide input. We offer quick feedback on your ideas and projects, and would love to hear what we can work on to make Apache Traffic Server even better.

9. References

1. 
   http://trafficserver.apache.org/
   
2. 
   http://www.monkey.org/~provos/libevent/
   
3. 
   http://software.schmorp.de/pkg/libev.html
   
4. 
   http://www.squid-cache.org/
   
5. 
   http://varnish-cache.org/
   
6. 
   http://www.nginx.org/
   
7. 
   http://haproxy.1wt.eu/
   

1 Not recommended by the maintainer

2 Only with completely separate process instances

3 Requires a recompile of the entire application

4 Squid v3 has plugin capabilities via eCAP

5 Using VCL scripting language and compiler

6 This is actively worked on

7 Round-Robin only at this point

8 Round-Robin and a random director

9 Partially broken at the time of writing this paper

10 Only between TS and client

Apache Traffic Server – HTTP Proxy Server On The Edge