status cache

[Bron Gondwana]

On Thu, Dec 18, 2008 at 05:30:22PM -0800, Andrew Morgan wrote:
> I'm getting ready to upgrade from Cyrus v2.3.11 to v2.3.13 on Saturday, 
> and I notice there is now a statuscache option listed in the changelog.
> 
> Bron, could you elaborate a bit on this option?

Sure.
 
> We run a reasonably large Cyrus installation (2 backends, 3 frontends) and 
> most of our users check their email via Horde Webmail.  Would the 
> statuscache benefit us?

Probably.  I'm not entirely sure what fields Horde requests.  Basically,
if it frequently does STATUS requests against folders, then you will see
a benefit.

It works by checking the modification time, inode and size of the index
file.  If none of these have changed, then it assumes the response to
status is the same.

It also checks the seen file stat if the status request covers items that
need a seen file lookup.

> Also, I've been sticking to mainly skiplist for all our database backends. 
> Would skiplist be okay to use for the statuscache?

skiplist isn't ideal.  We use the default of berkeley-nosync because
that's the most efficient for this access pattern (frequent writes,
always specific key requests rather than enumeration)

> Finally, is the information in the statuscache transient?  Would it be 
> safe to remove the statuscache.db file in between Cyrus restarts without 
> losing data?

That's what we do.

conf/cyrus/init.tt2
105:    system("rm -f $DATADIR/statuscache.db");

It's part of the startup script (yes, it is written in perl, and
template toolkit as well!)

Bron.