[imapproxy] (no subject)

[Eric Rostetter]

Quoting Johny <horde at agotnes.com>:

> I added some timings to the imapproxy source as downloaded from CVS today,
> and found the following;

This info is interesting, but not terribly useful without more info
like OS, mail server and mail store format, etc.

> Login to imapd takes ~64000 nanosecs (0.06 secs)
> Re-using a connection takes ~1050 nanosecs (0.001 secs)
>
> Pretty big relative improvement, however, the elapsed time taken is pretty
> minor to start with.

Not if your imap server is very heavily loaded.  An imapproxy is best used
when the server is under high load.  It may not be as effective under lower
loads.

> As for total elapsed time (which is what I really care about!), I measured
> this
> by using microtime() calls in mailbox.php and logging to the horde log. With
> an
> identical mailbox got the following numbers toggling between two pages with
> 20
> and 2 messages respectively;
>
> without imapproxy; 1.68 and 1.53 seconds consistently (varies by a few ms)
> With imapproxy   ; 2.6 and 1.8 seconds consistently

If most of your time is not with connection establishment or login (as you
state above) and your mailbox is trivially small (as you state above) then
(unless you have some major influence like slow nfs disk mounts) you won't
get much improvement.

> Which indicates a major increase in time caused by the proxy relaying the
> message headers, this outweighs by a long margin the overhead of starting a
> new
> imapd for every request and to my mind negates the value of the imapproxy in
> it's current form.

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

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.

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.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!