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

[Timo Sirainen]

On 22.6.2012, at 5.28, email builder wrote:

>> Oh, and of course it also depends on Dovecot configuration :) Authentication 
>> cache is needed and login processes must be in high performance mode.
> 
> I.e., I think:
> 
> http://wiki2.dovecot.org/LoginProcess
> http://wiki2.dovecot.org/Authentication/Caching

Yes.

>> There is 
>> still the extra work of forking a new imap process (could also be avoided with 
>> yet another config option)
> 
> Are you referring to client_limit or service_count or something else as yet undeveloped?

service imap { service_count = 0 } (default=1) allows imap processes to be reused for more than 1 connection. The downside is that if there are any bugs in Dovecot, they might accidentally expose another user's email data to the wrong user. That's very unlikely to happen but since this isn't a performance problem in most (if any) systems I don't want to enable it by default. Dovecot code is written so that write buffer overflows (= arbitrary code execution) is minimized to be as zero possibility as I could think of, but read buffer overflows (= exposing data within the process) isn't treated nearly as much with paranoia.

> Speaking of which, I cannot understand the different between those two.  Hints in the
> configuration file (10-master.conf) and the wiki make them sound like they do the same
> thing -- ??

service_count limits the maximum of client_limit. One connection = one service. Once a process has serviced "service_count" number of connections it disconnects itself. There can never be more than "client_limit" number of simultaneous connections. The important stuff to understand about these are:

 * service_count=1: The most secure setting for a process. The process serves a single connection and kills itself. No possibility of data leaking to unintended connection.
 * service_count=0, client_limit=1: The process does blocking operations (e.g. blocking disk IO). You don't want one connection's blocking operation to affect other connections. But you're not paranoid about security, since in case of some bugs some data might leak to unintended connection.
 * service_count>0: Restart process ever N connections, just in case it leaks some memory.
 * client_limit>1: Limit the amount of CPU/memory a single process takes. The process should never be blocking on disk I/O or locks or anything else. This means it shouldn't be used for imap/pop3/lmtp processes. For CPU bound processes it's fine.
 
Maybe these could be copy&pasted to the wiki2/Services.