Mark Thomas wrote:
On 21/10/2011 10:05, André Warnier wrote:
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).
Rather than making incorrect assumptions, you could check the source code.
So Tomcat, at any time, could maintain an ordered list of sessions with
their timeout timestamps (sorted by increasing expiration timestamp).
That is do-able.
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.
With this approach the question is which is faster:
a) iterating all of the sessions once a minute (or frequency of choice)
and discarding all those with (now - last accessed) > timeout
b) maintaining a list of sessions ordered by expiration time which is
updated on every request associated with a session
I have a hard time believing that:
1. b) isn't significantly more expensive
2. b) doesn't have all sorts of issues in a multi-threaded environment
Hard data will convince me otherwise but at this point I suspect b) is
considerably worse.
Allright, so how about a half-way house to start with ?
Keep the list in some thread-safe table, indexed by session-id, and just scan
the table.
Updating the corresponding session entry at each request should be cheap.
Of course in all this, my basic assumption is that currently, Tomcat keeps session
information (including the expiration data) in some location which requires an I/O action
to access.
If so, an immediate benefit of having a table in memory, may be that when a request comes
in with a session-id, the check of whether this session-id is still valid may be speeded
up significantly (as opposed to try to actually "get" the session info through an I/O and
maybe failing). And even if found in the table, the check on the expiration time would be
quick too. And if it is expired, deleting the entry from the table, and deleting the
session info through an I/O, may still be faster than first retrieving the session info
from disk.
Re-thinking about the above, an easier way to achieve a similar effect, may be to arrange
to store all session info onto something like a RAM-disk of course.
Basically my feeling is this : assuming for example 1000 on-going sessions, the background
thread needs to do at least 1000 I/O's (and probably many more) each time it checks for
session expiration. And this only to compare "now" with the session's expiration data.
Intuitively, this seems like a significant waste of I/O bandwidth, which could be avoided
at the cost of a bit of RAM.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
