bottleneck. In general, the dispatcher needs to be as fast as the average
service time, divided by the number of servers.
Application traffic is getting more dynamic and workloads are getting more
diverse. At the same time, true load-balancing technologies are getting much
faster, making them an attractive option. The load-balancing dispatcher can
take distribution and expected performance into account, as well as the exist-
ing performance of a system. Load balancing is a difficult problem to solve. To
achieve the most complete job, we must be able to estimate transaction dura-
tion and accurately measure the workload on a system. Even this measurement
can be problematic: what resources are constrained? An I/O bound system
may show a relatively low CPU utilization, though it is swamped. Most load
balancers opt not to solve all of these problems, and instead settle for effective
compromises and rich tools for specialization, configuration, and tuning.
Other interesting problems arise. If a system remains up but loses the ability
to do work (for example, if the database network connection goes down), it
will “complete” its tasks rapidly, though not with the desired results. If the
load-balancing algorithm is too primitive, this system will get most of the
work, with the load balancer systematically directing most of the traffic to the
wrong box. For this reason, load balancers usually are built to deal with some
aspects of reliability as well. The dispatcher can detect whether a given system is
down and dynamically take that system out of the rotation. It can also repeat-
edly route the same user to the same server, increasing the impact of caching
and simplifying implementations. Even so, queue specialization and workload
partitioning are still effective tools for solid, predictable performance.
Antipattern: Chaotic Session Management
When multiple web application servers are maintained, a user can be routed to
a different system with each subsequent request. In this case, load balancing
can make session state management much more difficult, or vice versa. Several
options are available for distributed session management.
Solution 1: Dispatching with session affinity
Some dispatchers will route a given user to the same server for every subse-
quent request. An association between the user and a server is called session
affinity. Dispatching with session affinity solves the problem by essentially
localizing the solution. If a given user will always hit the same server, the
application is masked from the distributed architecture.