[imapproxy] (no subject)

[Robert Brewer]

--On Monday, May 26, 2003 11:47 AM -0500 Eric Rostetter 
<eric.rostetter at physics.utexas.edu> wrote:

> You might try the up-imapproxy instead, as I find it has slightly better
> performance/acceleration low load systems like you describe.

We tried both imapproxy and up-imapproxy with our webmail system 
(SquirrelMail, hope that's not sacrilege :) and to our great disappointment 
found no real performance improvement with either proxy.

> I can say it does help on some systems.  The slower the login process,
> the more it will speed up the logins.  The slower the network, the
> faster it will make connections.  The larger/slower opening a mailbox
> is, the faster it will make opening/reading the mailbox.  Try it with
> a few hundred megabyte mbox file via wu-imapd, and you'll see a big
> savings: not from authentication time per se but from not having to
> reopen/reparse the mailbox file each hit.

Not sure if you are talking about up-imapproxy or imapproxy in the above 
paragraph, but my understanding is that neither really speed up opening large 
mailboxes. They only speed things up if your server takes a long time to set 
up the TCP connection or if authentication is slow. With wu-imapd, the big 
hit is all the disk I/O when you SELECT a mailbox, and neither proxy caches 
which mailbox you have SELECTed. Thus every webmail client session has to 
reselect the mailbox, and takes the I/O hit.

I recommended to the up-imapproxy author that SELECTs be cached in the proxy, 
but that turns out to be harder than it looks (since SELECT command provides 
some information like the number of new messages in a mailbox that can't 
easily be cached).

I'd love to be wrong on any of this, but I'm pretty sure I'm right and it all 
agrees with the performance data we gathered.

> This imapproxy seems to work best if your logins are slow for some reason
> (login via external server via ldap, smb, etc. that is slow) or your mailbox
> open/parse is slow (nfs mounts, giant mailboxes, etc).  If you don't
> meet these constraints, you may find better performance with another
> proxy like up-imapproxy or perdition (just to name two, and I've never
> used perdition so I can't speak to its value).
>
> Also, there have been discussions on this list of how this imapproxy
> can be slower on some OS versions (e.g. solaris) but faster on others,
> so you have to test it, and be willing to debug or try others to meet
> your needs, depending on your exact installation and setup.