Occasionally, I’ll find myself in a defensive position with regards to cookie persistence implementation. Some question it’s usefulness. Others have a concern about performance. I’ll try to address both here.
First, we’re talking about persistence. Most applications are stateful, so they require users be directed to the same server for each HTTP query. If they start up a session with one server, then get flipped to another, it’s like starting over. They have to log in again, any shopping cart is empty, etc.
There are two ways for a load balancer to keep persistence: Source IP address and cookie persistence. There are a few ways to do cookies, but the best, easiest way is active cookie, where the load balancer inserts a cookie into the HTTP session.
So first I’ll address the usefulness of cookie persistence.
For most connections, cookie persistence isn’t needed. Simple source-IP address persistence is fine. Most users manage to keep their IP address the same for at least as long as their session. However, with enough traffic, you will have users that experience one or more of the following:
- Knocked off dial-up mid session. Re-dials, gets new IP address
- Cable modem or DSL modem re-negotiates IP address
Another somewhat common scenario that is problematic for source IP persistence is when most of your users come from one office, and they’re behind a firewall. Everyone’s session is NAT’d to one source address, so everyone looks like the same user.
In most situations these are a minority of the connections, but it happens just enough to make cookie-persistence the best default choice in most situations.
And now, performance.
One common misconception is that cookies are slower. This is somewhat true, but not for the reason people tend to think.
First, it helps to know that in most (if not all) load balancing products, regardless of vendor, use two different code paths when it comes to cookie and non-cookie load balancing.
Layer 4 code path is simple NAT. It’s basically router code, and doesn’t go beyond Layer 4. Because of the simplicity, there’s relatively small impact on the CPU.
Layer 7 code is actually a type of proxy. It’s a web server, like Apache or Squid. There’s a larger memory footprint for this of course, and there’s a lot more going on (parsing of cookies, inserting cookies, etc.).
When it comes to user experience, one isn’t faster than the other, despite the difference in CPU resources used. One is not faster than the other in terms of user experience.
There is a difference in capacity. A system that can handle 4,000 Layer 4 connections per second might only be able to handle 1,000 connections per second of Layer 7 traffic. And the performance profile of most load balancers has load balancing responding to client connections with the same speed until capacity has been reached. The load balancer, whether Layer 4 or Layer 7, responds the same whether there are 10 connections per second or 800 connections per second.
Even approaching the system’s performance limit, things still run smoothly. There’s a wall though, and once it’s hit, everything starts to get really slow.
This is the same for Layer 4 and Layer 7. The only difference is that it happens at a lower connection rate with Layer 7 than it does with Layer 4. But because of Moore’s law, the low-end load balancers today can handle more connections than the high-end boxes of 5 or 6 years ago.
So when people talk about Layer 4 being faster, it really means that there’s a higher performance ceiling. User-perceived performance is the same.
