What Application Developers Need To Know About Load Balancers

You’re an application developer. You work in a world of untyped variables, debugging, and hitting reload over, and over, and over, and over again, all in the name of churning out a good web app. You can spot a SQL syntax error from the corner of your eye, and you’re the go-to guy (or gal) for your company.

But what you don’t know much about is load balancers. So here’s a bit of a primer on load balancing for those involved with application development.

Persistence

The first thing you need to know about is persistence, and specifically, do you require it. If your application is stateful, where information regarding a session is stored on only one server, you’ll need persistence. Virtually all load balancers support this, but you’ll need to know to turn it on (or ask your load balancer administrator to turn it on).

Most applications are stateful, so it’s a fair bet you will. A quick way to test is to start a session on one server, then change the hostname or IP address in your browser to point to another server with the same application installed. Does it break, act freaky, or otherwise malfunction? Then you’ll need persistence.

As I’ve said several times before, you’ll probably want cookie persistence.

What The Load Balancer Passes On To The Server

Sometimes I’m asked what the load balancer changes in the client request to the server.

The answer is: absolutely nothing.

Load balancers will pass all HTTP headers that it receives onto the server. It may add a few items, such as a persistence cookie, but in most configurations, the load balancer won’t change anything (and with many vendors, the load balancer just doesn’t have the ability to change anything).

A load balancer might give out an HTTP 302 redirect. A very common example is redirecting from HTTP to HTTPS.

Virtual Hosting: The Host Header

This is often called software virtual hosting, virtual hosting, etc. Basically, it’s running more than one URL off the same IP address.

Let’s say you’ve got two URLs: www.domain1.com and www.domain2.com. In DNS, they both point to the same IP address, yet when you go to the sites with a browser, two separate web pages come up. How come? It’s all in the HTTP host header.

When the browser makes a request, it includes a “Host:” entry, telling the web server what host it’s looking for. The web server looks at this host, and serves up the appropriate page.

The load balancer will forward this host request along with the entire request. Most load balancers don’t have the ability to even change this.

SSL Termination

If you utilize SSL on your web site, you may want to consider having the load balancer terminate the SSL connection.

You’ll want to check to see if the load balancer has hardware acceleration, which is a special card that removes the SSL encryption/decryption operations from the general CPU and onto a specialized processor.

The two main benefits to SSL termination are the performance benefit by having the load balancer handle the SSL instead of your servers, and by terminating the SSL connection on the load balancer, you can use cookie persistence.

Header Dump

It helps to have a method, in either a standalone page or in your own library as a quick function call, to dump all the HTTP header variables.

In PHP, you can use the built-in phpinfo() function.

<?php
phpinfo();
?>

Have this page/function handy, in case a problem arises.  Point your load balancer administrator there, and they may be able to point out the problem.