On 26.6.2010, at 3.08, Brandon Davidson wrote:
We run a proxy instance on each of the webmail hosts, with the communication between the web application add the proxy being done in cleartext, but with the proxy -> Dovecot communication secured over SSL. Besides preventing a lot of extra SSL handshakes and login/logout actions,
Yes, SSL handshakes are extra. Although SSL supports some kind of quick renegotiation too, but Dovecot doesn't support that yet. No one's ever requested it..
it also helps tie a user session to a single backend node in our pool of IMAP servers. It seems like there might also be other benefits to having Dovecot not tear down all of the user session state between page loads.
Some, but I suspect mostly CPU performance related (which usually doesn't matter).
A lot of this stuff might be nice to see in the Director some day. If there was an option to not immediately close the Director proxy's backend connections when the user logs out, (ie leave the connection active and logged in for X seconds, and reuse it if the user logs in to the Director again),
It hasn't really ever been in my plans to do anything like this. A separate imapproxy program for this is probably better. At least I don't really see any benefits compared to it if it was done by Dovecot.
I mainly just wish someone would give some kind of real numbers when running with and without imapproxy with Dovecot (and not some other server they used to run years ago) when they're talking about imapproxy helping the performance a lot. So far the best reports I've heard are "imapproxy improves a little bit, but adds too much complexity/fragility". So I'm a bit sceptical about using it.
I've also recently heard from a large installation who was complaining about Dovecot's memory usage (compared to Courier). imapproxy would definitely make their memory usage a lot higher, since the connections would stay around for longer. Although I'm still wondering why Dovecot would take so much more memory with large maildirs .. should look into that some day.