Paul J Stevens wrote: > I've been rather busy keeping my business afloat doing paid-for production > work > lately.
No problem at all. > The problem by now is well understood; repeating the same command > sequentially for many messages in the same mailbox needs to be > optimized using server-side caching. This works for a threaded model. It won't work for a multiprocess model unless you're making use of some sort of shared memory setup. See below. > 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. > - 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. I think the proper fix here may be to have the server store a timestamp in the mailbox that is updated whenever the mailbox is updated. When a STORE occurs, the first thing it does is read the timestamp. If it doesn't match the cached value then do a db_getmailbox(), else perform the STORE operation and, as a part of it, update the timestamp (and the cached value, of course). We may already be storing the timestamp. I'll have to look. > that's about all I can think of at this time. Did you file a bug > report for this issue already? If not, please do, so I can dig into > it at a later moment. OK, I'll do that a little later when I have time. By the way, I'm a little underwhelmed with the bug tracking system, based on what I've seen of it. It should automatically listen to this mailing list and whenever it sees a reply to a bug it should add the contents of the reply to the bug. It's annoying to have to deal with multiple interfaces just to get the complete history of the bug, since some of that history comes from discussions here while the rest of it is in the bug tracking system proper. In general, I find that email works much better for most bug-related correspondence. -- Kevin Brown [EMAIL PROTECTED]
