On Mon, 15 Aug 2011 16:57:14 +0300, Pascal Gienger <pascal.gienger@xxxxxxxxxxxxxxx> wrote: > Just a little remark: > > We have > 4000 connections in IDLE state(*) and idled works flawlessly. > I had some headaches because some members of this list pointed out that > imapd was not tested for thousands of connections. > > It justs works. > > Cyrus IMAPD 2.3.19. Typo I'm sure ;) I've never seen 2.3.19 in the wild. > (*) due to a heavily migration to Thunderbird including Lightning > (connecting to our SOGo servers) in many of the faculty and professors' > secretaries. I don't believe idled has any real dependency on the number of open connections for load purposes - just on the number of actions that happen to idled mailboxes. Now what you will find is that idled communicates by throwing processes around, so if you have heavy process churn and a small pid space, then processes which died without telling idled about their being closed (for whatever reason - in our case nginx proxy restart usually) then you'll get random processes being killed by the idled signal monster. It is kinda happy to throw random SIGUSR1 and SIGUSR2 at processes without checking first if they're still the same process. But it's all hash tables internally - there's no reason it won't scale up to big numbers. Bron. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
