IMAP Performance (again)

[David Mackintosh]

On Tue, Aug 23, 2005 at 03:27:52PM -0600, karlp at ourldsfamily.com wrote:
 
> BUT, I have figured something out. Whenever an Outlook Express IMAP user
> accesses the server, it's unbearably overwhelming to the system and causes
> incredible slowness. When Pine or Squirrelmail users access the system,
> there's no noticable performance hits. With Pine, I understand because it
> doesn't access all the folders everytime it tries to update things.
> Outlook Express does this, as does Squirrelmail if the option is set. With
> the option set in Squirrelmail, it doesn't hit the server as hard as
> Outlook. Or, have I been smoking something? (don't answer that)...

In my experience, we had extreme performance slowdowns when using the
UWash imapd.  What was happening is that the users had large spools
or folders, and since UWash was spawning a new instance every time
someone connected to it, nothing about the mailbox(es) was getting
cached; which meant that these large spools or folders had to be read
each and every time the folder was accessed.  Multiply this by
extreme email hoarding (people with a gig in their inbox spools were
not uncommon) and volume (over 150 people accessing the server) and
you had for a very large, very powerful computer doing nothing but
waiting on disk I/O.  

Our solution was to use the cyrus IMAPd.  This uses a different
format for storing email, but more importantly the message statuses
were stored in a database format separate from the actual messages,
which meant that folder status queries (ie, anything new in my
inbox?) were much lighter, more likely cached, and due to both
reasons, much faster.  

The learning curve for cyrus is much steeper than UWash (especially
if you are doing either virtual domaining and/or building from source
on Solaris); but in our case it was well worth it as it saved us the
cost of a brand new machine.

-- 
 /\oo/\
/ /()\ \ David Mackintosh | Public Key: 
         dave at xdroop.com  | http://www.xdroop.com/dave/gpg.html
         $ gpg --recv-keys --keyserver subkeys.pgp.net 4C032504
         Mystery attachment?  http://xdroop.dhs.org/space/GPG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/redhat-install-list/attachments/20050824/20085929/attachment.sig>