Stan Hoeppner wrote:
Charles Marcus put forth on 6/27/2010 11:37 AM:
I think what matters is that the number of connections that TB is expecting to be able to use be *less* than the max supported by the IMAP server. I do know that as soon as I changed the MAX number of connections per IP in Courier to 5, all of our problems went away.
When you get a chance fire up top and take a look at the CPU time used by each of the 5 imap processes associated with a given TB user. Four will be at zero or maybe one or 2 seconds. You'll see the vast majority of the CPU time is on the fifth imap process.
This is exactly why I limit TB to one connection. My mildly educated guess is that the other 4 connections are being used strictly for IDLE processing, if at all. For me the additional 4 unused or rarely used connections isn't worth the additional overhead, even though said overhead isn't terribly high. Having 250 imap processes running on the system for 50 logged in users is something I just can't stand, given that 50 imap processes have no trouble servicing those same 50 users.
Thunderbird is a modern threaded application, users are able to perform many parallel actions. The IMAP protocol returns data for one action at a time, so in order to follow through with the user requests, it delegates commands to multiple connections. This may not be apparent when dealing with mail folders with few messages that have actions completing in a few seconds, but when dealing with large amounts of data the need for multiple connections becomes apparent (unless you're a patient person ;)
Hopefully NOTIFY fixes all of this, and hopefully TB and Dovecot will support it before too long. As is, I'm more than happy with single connections and polling, and one imap process per user. The big downside to my setup? Users might have to wait up to 60 seconds for a new email notification. However, they don't know they waited 60 seconds, so what does it really matter? As far as they know it just now arrived.