The Reiser 3 file system was built to handle millions of files in a
directory effortlessly. And, unlike many other file systems, it is
space efficient with tiny files like this. If you’re using Linux, then
this is a good solution for your session storage. (though perhaps more
difficult to retroactively fit :).
Ext3 now has directory hashing too, but I don’t think it’s enabled by
default, and I’ve not tested it’s performance.
Looking at the FileStore code though (from actionpark 1.13.3, it cannot
be trusted to atomically update fragments in a multi-process setup
(though it seems to be thread safe). This means you could conceivably
read a fragment as another process is writing to it, and get a broken
session object or corrupted cache fragment.
If you’re using an OS with an atomic rename system call (like Linux, and
probably any UNIX) then you could tweak the FileStore code to avoid the
race. If not, and you still want to use FileStore, then I’d recommend
using one FileStore object over drb.
If you store sessions in memcached, bear in mind that when its ram pool
fills it will automatically expire entries that have been used the least
This might be more detail than is necessary for the original poster, but
maybe it’s useful to someone.
On Mon, 2007-04-16 at 20:24 +0200, Florian G. wrote:
Thats a problem that could also be solved by dividing sessions in
multiple folders (take numbers and search your folders). The main
Problem of pstore is that it spams one folder - a scenario that files
systems are not build for.
As for cons against DB based store: as i mentioned before, it’s
performance is not database-agnostic, while pstore and memcached