tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [OT?] control of session timed out with tomcat
Date Fri, 21 Oct 2011 10:42:16 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message