[Dovecot] dovecot evaluation on a 30 gb mailbox

[Michael M. Slusarz]

Quoting Eric Rostetter <rostetter at mail.utexas.edu>:

> Quoting "Daniel L. Miller" <dmiller at amfes.com>:
>
>> I know when I was playing web clients - particularly squirrelmail -  
>> there was a definite perceived improvement - but I never measured it.
>
> Webmail clients are basically stateless.  Over time, they have "cached"
> some info for performance, but basically they are still stateless.  So
> almost any time you click on a link dealing with an email (delete, purge,
> next message, forward, etc) it has to open a _new_ connection to the imap
> (or pop) server, which means a new login.
>
> Simple proxies (like say perdition) don't help, as each connection will
> still be a new login.
>
> Some proxies (like imapproxy) however can keep a login session open, with
> the proxy caching the authentication issue.  For each connection after
> the first, it can do the authentication itself and use the existing login
> connection to the pop/imap server, avoiding a login for each operation after
> the first (until a timeout is reached).  By avoiding the constant  
> login/logout
> cycle, it will generally perform at least slightly better with the proxy
> than without (no new connection overhead, no login and logout overhead, same
> over head most everywhere else unless the proxy's authentication is slow).

However, imapproxy (at least as of v1.2.6) is still less than  
desirable.  Even though you are saving on the authentication overhead,  
every time your stateless client (i.e. webmail) connects it still  
needs to potentially issue a CAPABILITY command and/or other enabling  
commands (e.g. 'ENABLE QRESYNC').  So that's still a bunch of overhead  
that could potentially be saved.

Solution: make the imapproxy layer visible to the client.  Patches  
were added to imapproxy v1.2.7 to do just that.  When IMAPPROXY is  
being used, XIMAPPROXY is announced via the IMAP capability string.   
More important, if the cached proxy connection is successfully reused,  
a XPROXYREUSE status response is returned after the authentication  
commands are completed.  If this status return is observed by the  
client, it knows that it can reuse its cached information about the  
connection (if it exists locally on the client) without needing to  
check on CAPABILITIES or issuing ENABLING commands.  Additionally, it  
can prevent unnecessary initialization code on the client side that  
only needs to be done when a user logs into the server.

IMP 5 (more specifically, the Horde 4: Horde_Imap_Client socket  
driver) does just this to prevent unnecessary traffic to the IMAP  
server.

michael