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.
