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

[email builder]

>>>  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.

So really, a new process is created under *two* circumstances?  1. when a
process reaches client_limit number of *simultaneous* connections or  2. when
a process has serviced service_count number of connections.  Is this correct?

So for service *-login, is it OK to do something like service_count=5000, client_limit=2000

Thanks for the help!