tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <jimc...@iname.com>
Subject Re: Distributed Session Server
Date Thu, 29 Jun 2000 17:18:09 GMT
One of the more complex problems associate with any session management
architecture is the removal of expired sessions. In theory, this is
performed very easily by iterating through the sessions and removing those
that haven't been accessed recently. In practice, this solution does not
scale very well.

On very high demand servers, there may be a few hundred thousand sessions
active. The task of culling this list causes a perceptable performance lag.
I would conjecture that most session implementations for nearly every web
server use this approach. I don't have emperical evidence that this is true,
but it is the simplest solution, and the simplest solution is usually the
one implemented.

Even if you simply sweep an in-memory hashtable, you have to do so in a
thread-safe manner. Typically, you have to synchronize on the hashtable
itself. When you do this, the many hundreds of incoming requests are on hold
until you have removed stale sessions. If you are passivating these stale
sessions in the same thread as you are culling them, there would be
unacceptable performance.

One viable approach to this matter is locking only a portion of the session
list, which requires a much different implementation of collections. Other
approaches would involve keeping a few smaller session lists, and removing
sessions from them individually. The trick is to keep only (pick a number)
10K - 25K sessions in a list. Something that can be iterated through fairly
quickly without affecting all of the incoming requests.

I would be interested in knowing if any list readers have other suggestions
on how to effectively deal with very large numbers of sessions. As you see,
this problem transcends the basic question of where state is held. it also
provides an effective argument *pro* sticky sessions, as each webserver is
effectively a subset of the entire session population.

jim


Mime
View raw message