The last portion of the WebGUI 8 memcache switch is to see about caching hot sessions. Before I get into how I'm looking to do it, I figure it might be worth talking about what happens now.

Currently on every page view the session is read from the database, and then written back to the database. The write to the database is necessary so that we can update the session so that it doesn't time out. Unfortunately this means there is a read and write to the database on every page view even if the entire page can be served out of cache (there are others too, like settings, but that's a whole other ball of wax). 

We use the database for this rather than a local cache on each web node because in a load balanced environment a user can safely hop between web nodes and not lose their session. In addition, if a particular web node goes down, it only affects that one request, and the next request can be picked up by another web node. 

My plan of attack for this is to add memcached to the mix. It would work like this:

If the user sends a session cookie, we check cache to see if the session can be loaded from cache (its a "hot" session). If it is we load it from cache and increment a hit counter in the cache for that session. Then after the hit counter reaches a configurable level (3 lets say), on that request the session will be written back to the database. If its not in cache (its a "cold" session), we load it from the database, and write to the database to update the session with current timeout info.

What has this gotten us? Well, first we're only reading a user's session from the database if it's not already in cache. So we've likely reduced the "reads" from the session table down to once per session. So if the user views 10 pages in their session, then we've taken 9 reads off the database. In addition, since we're only writing every 3 requests, we'd write on the first, the fourth, the seventh, and the tenth. So instead of 10 writes to the database we now have 4.

There are two downsides to this approach. The first is if the user only hits 9 pages, then their session timeout data won't be written back to the database, which means their session could time out earlier than expected. If that's a problem then simply set the max hit counter to 1 and the session will be written to the database on every page view, but will still only be read from the database on the first page view. The second downside is that if the memcached server is restarted or crashes then the most recent session timeout data may not be written to the database unless the hit counter is set to 1.

Beyond just raw session timeout data we'd also adopt this approach for scratch variables. The only difference would be that whenever a scratch variable changes that's the only time it would be written to the database. Other than that, scratch would only hit the database the first time (when it's cold), and from then on would be served out of cache.

Any comments, questions, or scathing rebuttal?