[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