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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
