[Dovecot] Overly long email of miscellaneous Dovecot migration questions

[Mark Moseley]

On Wed, May 26, 2010 at 3:11 AM, Timo Sirainen <tss at iki.fi> wrote:
> On Tue, 2010-05-25 at 23:27 -0700, Tim Traver wrote:
>> >> Since Exim wouldn't be touching the index files, is it safe to leave
>> >> exim as-is and let it handle the deliveries to the maildirs natively?
>> >> Exim's already got access to everything it needs including the quota.
>> >> I just want to make sure I won't horribly corrupt anything leaving it
>> >> as-is -- but I'm also desirous to not have to mess with how deliveries
>> >> are currently being done.
>> >>
>> > That's fine.
>> >
>> >
>>
>> ok, but wouldn't that negate the point of the dovecot deliver being able
>> to immediately update the index so that it wouldn't have to be rebuilt?
>
> Index is never "rebuilt", it's "updated". If you don't use deliver, the
> main noticeable difference comes if user has a lot of new mails, and
> client fetches all of their headers. Since they're not in cache file
> yet, there's a delay until they're all read and parsed.

Yeah, we're doing exim deliveries straight to the maildir, so there's
no MTA effect on indexes. I'm sure that there's some non-negligible
performance hit doing things this way. The upshot though is that it's
so *very* much better performing that with courier+NFS that everyone
is happy: netapps aren't creaking under ops/sec load, so users' IMAP
and webmail are much much faster and execs are happy that they don't
need to immediately buy more netapps to deal with heavy load.

I've attached a slightly cropped rrd graph of NFS read bytes/sec on 6
mail netapps from one of our datacenters. See if you can spot where we
started moving IMAP to dovecot over the course of about a month :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfs.png
Type: image/png
Size: 48438 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20100526/e5a70bd7/attachment-0001.png