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