[Dovecot] Dovecot performance under high load (vs. Courier)

[Michael M Slusarz]

Quoting Timo Sirainen <tss at iki.fi>:

> On 23.6.2012, at 13.21, Ed W wrote:
>
>>>> But I don't know, whether this is the sort of caching you are  
>>>> referring to.
>>>
>>> what's a point of caching imap, except your webmail service is not  
>>> locally connected (localhost or LAN) to imap server?
>>
>> Asking for items 600-615 from a threaded list, sorted by something,  
>> can be an expensive operation, especially if you just asked for  
>> items 585-600 a moment ago?
>
> Can be, but is it? :) Dovecot attempts to cache/index stuff as well.  
> Normally there shouldn't be a need for extra caching layer except in  
> cases of higher network latency.

Timo: I'm not sure if you are saying that all client-side caching is  
wrong.  If so, I'm going to disagree with you, especially when dealing  
with more complex data structures.

Let me first say that I don't take IMAP response parsing to be a  
computationally easy action.  So it's not just network latency you are  
worrying about; parsing a line can be the limiting factor in many  
cases.  For example, a deeply threaded 400 message mailbox will return  
a THREAD response line that will take quite a bit of recursive parsing  
to decode.

And various FETCH criteria most definitely benefit from local caching  
above/beyond what dovecot provides.  An example: BODYSTRUCTURE.  This  
may be cached on the dovecot side, but when received by the MUA you  
have to parse the IMAP BODYSTRUCTURE response (not trivial).  You also  
have to potentially handle IMAP response codes in the server command  
completion line.  And the bodystructure data is probably not all that  
useful until converted to a usable object on the MUA side, which may  
be another relatively expensive operation.  So a locally cached  
bodystructure object is a substantial performance benefit over having  
to recreate this data from the cached data on the dovecot side.

ENVELOPE is similar.  Most likely this will be converted to an object  
representation in the MUA so you have the same benefits as  
BODYSTRUCTURE.  Additionally, in IMP we do things like scan for broken  
charset headers (e.g. Subject headers that contain non-ASCII  
characters) and have some algorithms to fix these issues.  This  
"value-added" code would be prohibitively expensive if we have to do  
it on every mailbox access.

Message flags are another benefit to caching.  The list of flags may  
be cached on dovecot, but not having to issue a flag FETCH every time  
you access a mailbox can be a substantial benefit.

But I will heartily agree that nobody should be caching things like  
headertext or bodypart data.  There is little/no benefit you receive  
from caching this locally.  This is where you should be leveraging the  
storage on the IMAP server.

As an MUA author you can't rely on the fact that you are connecting to  
a competent IMAP server.  You just as likely are going to be  
connecting to a server that implements base RFC 3501, and most likely  
implements that incorrectly.  Not all of us are lucky to connect to  
Dovecot (or Cyrus).

So smart caching most definitely can and will increase performance of  
an MUA, regardless of caching performed by the IMAP server.

michael