Mark Thomas wrote:
On 20/10/2011 17:01, Tim Watts wrote:
On Thu, 2011-10-20 at 16:35 +0100, Mark Thomas wrote:
On 20/10/2011 16:22, André Warnier wrote:
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier <a...@ice-sa.com> wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time
checking all of them repeatedly on the off-chance that one has expired ?
It is handled by the background processing thread. By default that
thread runs every 10 seconds and ManagerBase triggers a session
expiration check every 6 runs by default. So in short, they are checked
roughly every 60s. The test is pretty simple so it doesn't take very
long at all.
Or is there a smarter algorithm implemented there ?
Such as? I'm open to ideas here (maybe not for this exact problem but
certainly the general one).
Not necessarily claiming "better" but:
* find the oldest session
This can change dynamically since application code can change the
session expiration time at any point.
* go to sleep until it's ready to expire (since you know nothing
interesting will happen before then)
* wake up and expire sessions that need expiring
* repeat
Of course, this would require a dedicated thread. If the background
thread handles more tasks than just expiring sessions there's probably
not much gain in doing this approach. Or you could use the 'find oldest
session' value to compute how many work cycles to skip until the next
actual check. Is the complexity worth the savings in CPU cycles? Eh,
probably a wash. Could set a minimum threshold and only use the computed
value if it's greater than the threshold. Incorporate the computation as
part of the session scan.
But you did ask... :-)
If session expiration time was constant, this would be fine.
Unfortunately, that is not the case.
How about..
I am assuming that at each access to the application, Tomcat updates the expiration time
of the session if any (that is, it sets a new date/time at which this session will be
considered as expired, being "now" + timeout).
So Tomcat, at any time, could maintain an ordered list of sessions with their timeout
timestamps (sorted by increasing expiration timestamp).
Now whenever the background thread goes into its "check for expired sessions" cycle, it
could start at the beginning of the sorted list, and stop as soon as it encounters an
entry with an expiration time which is later than "now", because any entry beyond that
point is of course unexpired.
The sorted list needs to contain only the session-id and current expiration timestamp, so
it should not be that costly in terms of memory. (*)
In my personal experience, systems nowadays tend to be limited more by their disk I/O
speed than by CPU usage. Despite the more complex logic required by keeping the ordered
list ordered, and considering that sessions are usually created/kept for a "considerable"
length of time, I have a feeling that this might provide a performance boost, all the more
important as the number of sessions increases.
Also, when checking a session for expiration, Tomcat would not actually need to read each
session's info to get its expiration time and decide to delete the session. It could just
check the entry in the list, and delete the session info immediately if it is expired,
without needing to read it.
(*) I would even not be surprised if there existed already in memory some form of table
representing the current sessions.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
