[Dovecot] First time Dovecot user, really impressed so far. What is best IMAP enabled webmail package to go with Dovecot?

[Stan Hoeppner]

Rick Romero put forth on 1/4/2010 3:14 PM:
> 
> Are you sure the CPU is pegged from CPU and not disk I/O?  I used to
> import 160GB of InnoDB data on a quad core (U320/RAID 10) and after the
> cache would fill up, only 1 core would show as pegged because the disk
> I/O wasn't fast enough.  Seems like the index on 10k messages might be
> kinda big.  Got more RAM lying around?  Just a guess.

I guess I didn't look closely enough before stating that.  I saw an imap process
eating 99 %CPU and 'assumed' it was one thread, which is usually the case when I
see one process listed as 99% in top.  Upon further inspection, it would seem
it's more than one thread, but the combined CPU usage is being shown in top as
99, which fooled me upon first glance.

top - 23:09:04 up 23 days, 22:49,  1 user,  load average: 0.08, 0.02, 0.01
Tasks:  50 total,   2 running,  48 sleeping,   0 stopped,   0 zombie
Cpu0  : 59.2%us,  4.9%sy,  0.0%ni, 34.9%id,  1.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 32.1%us,  3.0%sy,  0.0%ni, 64.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    387044k total,   331396k used,    55648k free,    22808k buffers
Swap:   995988k total,      428k used,   995560k free,   239544k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9161 stan      20   0 26776  22m  22m R   99  6.1   0:10.77 imap

As we can see from the 1% I/O wait on CPU0 and 0% on CPU1, it's seems pretty
clear that the CPUs are being occupied by the dovecot search code, not by disk
I/O.  Recall that I'm using mbox format, so we're dealing with a single file
with 10,600 email messages within, not 10,600 individual files as is the case
with maildir.  This particular mbox "folder/file" with the 10K+ messages is 46MB
in size.  There are few users and the host is very lightly loaded at this point.
 My guess is that this file has been wholly (or very nearly so) cached in the
Linux page and/or buffer caches.  This would tend to explain the phenomenal body
search speed on such low end hardware.

> I like Horde (extendability) and Roundcube (speed), and would recommend
> using imapproxy for either webmail system.  It helps speed things up.

I've looked a little at both now and am still reading.  One thing I don't like
is that I'm seeing requirements a SQL server.  That adds unnecessary complexity
to the system and I'd rather avoid it if possible.  IIRC, one of the reasons I
chose Squirrelmail a few years ago was that it's requirements were pretty
simple, and that it didn't require a database backend for anything.

--
Stan