Sticky session means that when a
request comes into a site from a client all further requests go to the same
server initial client request accessed. I believe that session affinity is a
synonym for sticky session.
Both mean that when coming in to
the load balancer, the request will be directed to the server that served the
first request (and has the session).
The problem is "sticky
session" where each user is assigned to a single server and his/her state
data is contained on that server exclusively throughout the duration of the
session.
Pros
- it's easy-- no app changes required.
- better utilizes local RAM caches (e.g. look up user profile once, cache it, and can re-use it on subsequent visits from same user)
Cons
· if the server goes
down, session is lost. (note that this is a con of storing session info locally
on the web server-- not of sticky sessions per se). if what's in the session is
really important to the user (e.g. a draft email) or to the site (e.g. a
shopping cart) then losing one of your servers can be very painful.
· depending on
"sticky" implementation in your load balancer, may direct unequal
load to some servers vs. others
· bringing a new
server online doesn't immediately give the new server lots of load-- if you
have a dynamic load-balancing system to deal with spikes, stickiness may slow
your ability to respond quickly to a spike. That said, this is somewhat of a
corner case and really only applies to very large and sophisticated sites.
Comments