On Mon, 2006-01-09 at 15:13 -0800, Kevin Brown wrote:
> Paul J Stevens wrote:
> > In this particular case:
> > - the acl calls shouldn't be triggered every time when the acl for a
> > particular mailbox has already been established. In general, the acl
> > calls for a mailbox are too expensive already (a known bug), but in
> > this case they are called many times as well, an unacceptable
> > situation.
> 
> Perhaps, but that's not where the bulk of the time is spent.  Those
> same calls are made on small mailboxes as well, and the update speed
> on those is quite good.
> 
> I won't argue against dealing with that as well, but I think the
> low-hanging fruit should be picked first.

My idea for speeding up the ACL calls is twofold: first, always grab all
relevant ACL's in one query, then process the results for the individual
fields; second, store that information in-process for later use (which
is typically the next 10 calls to the getacl functions).

> > - since store doesn't change the mailbox, db_getmailbox should not
> > be called if the ud->mailbox structure is still up-to-date; that is,
> > if the previous command was also a store command we can assume to a
> > certain (limited) extend that the mailbox hasn't changed. This means
> > we should defer db_getmailbox to situations where the ud->mailbox
> > structure appears to be out-of-sync.
> 
> Nope, you can't make that assumption.  The reason is that IMAP
> supports multiple simultaneous writers.  If the mailbox changes out
> from underneath you then you need to realize that and recompute
> things.  Right now we're recomputing things every time so this hasn't
> been an issue.

Global variables, as I alluded to, and shared memory, as you mentioned,
do not replicate. It's entirely possible that the database changed not
just under the noses of the processes on this machine, but on other
machines, too!

I think the best solution for now would be to use a table to hold the
cache. Queries that take a long time to calculate but return simple
results can just stuff those results into the cache table and have big
speedups. Timestamps could be stored for things like the ACL
information, so that an ordinary static variable can live in the getacl
function and the ACL queries made only when the timestamp changes.

Aaron


Reply via email to