Quoting Eric Rostetter <rostet...@mail.utexas.edu>:
Quoting "Daniel L. Miller" <dmil...@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
