[dev] Authentication session data cleaned by Kronolith

Michael M Slusarz slusarz at horde.org
Tue Jun 25 16:52:51 UTC 2013


Quoting Michael M Slusarz <slusarz at horde.org>:

> Not necessarily.  There are a finite number of large slabs allocated  
> by memcache.  If on a server with a number of users, these large  
> slabs are necessarily limited (especially if caching other data), so  
> they are potentially going to get reallocated to another user.  This  
> will cause the original user's session data to be incomplete, and  
> their session will be invalidated/timeout.

More details on slab allocation:

http://www.adayinthelifeof.nl/2011/02/06/memcache-internals/

I was incorrectly calling Memcache a FIFO cache, but it is really a  
LRU (least recently used) cache.

The main problem with memcache: as of right now, there is only 1  
method in Horde of guaranteed data storage: the session.

We can't rely on Horde_Cache since 1) there is no requirement an admin  
configures it and 2) well, it's a cache, which by definition !=  
persistent storage.

What we need is guaranteed data storage that is guaranteed to be  
deleted at the end of a session.  Session storage is really the only  
solution, at least at this time.  It might be nice to somehow have an  
overlay to session storage for data that is "less frequently used",  
but this currently doesn't exist.  We work around this some within the  
session data itself by using tricks like individual data compression  
and on-demand serialization, so that we are essentially "ignoring"  
those portions of the session data that we don't use in a page access.  
  However, all of this data DOES need to be read from the session  
backend (and potentially written to the backend if something changes  
in the session), so it is not ideal.

Memcache simply is not designed to hold this kind of larger  
information.  It was designed for things like caching database results  
- where you don't want to spend a lot of time storing the data, since  
the underlying data may be dynamic and changing - but was never  
designed to be even a half-hearted attempt at data persistence.  All  
of these attributes make it a terrible choice for a session storage  
backend.

This is one of the main reasons I wrote the Redis backend for Horde  
5.1.  Redis is essentially an improved version of memcache, that is  
useful in a wider variety of applications.  There is realistically no  
performance difference between the two (especially accounting for the  
need to do a bunch of workarounds in user-land code to bring necessary  
functionality when using a memcache server).

michael

___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the dev mailing list