#1 Cache gets too big too quick

[John Keiser]

Right now the way we cache is ugly. The problem, in
brief, is that the cache hash continually gets bigger
as more and more people access the system. The cache
hash is then (in Mason) stored in a file, and read back
at the beginning of each request.

Ways to improve the cache:

1. Limit the size of the object
* Don't store sessions in the Mason cache at
all--just store system parameters and attributes (best
short term solution).
* Make an LRU cache
* Have the cache periodically dump sessions that
haven't been accessed in a while
* Have the cache periodically dump itself entirely

2. Limit what is retrieved on each read
* Go to shared memory instead of Mason cache (setup
problems?)

If we can find a way to make a database index (or
view?) that keeps the last n accessed entries around
for quickest access, then perhaps not caching sessions
would be good too. NOTE: sessions and users would
still be cached *within a given pageview*. There's no
justification to re-fetch that information during that
time.

[John Keiser]

Logged In: YES
user_id=312414

This bug is now partly fixed ... it turns out the cache was
already getting really big.

Looking at the size of the cache in Mason, it looks like
it's still a lot larger than it should be ... perhaps Mason
serialization makes things bigger than they need to be. (I
have checked the value before it goes in and it's not *that*
big anyway.)