[Dovecot] Creating an IMAP repo for ~100 users need some advice
Robin
dovecot at r.paypc.com
Mon Mar 19 23:11:25 EET 2012
On 3/17/2012 12:36 PM, Sven Hartge wrote:
> Storing mails inside SQL? Not supported by dovecot and not very wise,
> IMHO. DBmail does this, but to be honest, I never heard any good
> feedback from admins using that product. From what I have been told, you
> need quite the beefy server to get a decent performance out of DBmail,
> compared to the needs of a "traditional" setup like with dovecot or
> courier-mail, but I digress.
Ugh, I've tried the product. It works pretty well, until you move more
than a small handful of users and email hives to it, and you hit some
hard walls pretty fast with how many inbound emails/second it can handle
for even burly server configurations.
Those hard walls occur at too low a threshold for me. The product's
mailing list is supportive and there are many dedicated DBMail users who
step in an answer questions, but be prepared for "BUY MORE RAM" as the
answer to concerns about performance. When 128GB of RAM is needed for a
small organisation's email setup to perform well, I am strongly inclined
to move on to the next product.
Best practices for it seem to revolve around being able to have your
ENTIRE email + index content resident in RAM. Well, gosh. Why didn't I
think of that before instead of wasting all of this time worrying about
design and efficiency?
And if you're hoping that it will make text searches "automagically"
fast, think again.
Timo's FTS_SQUAT blows it out of the water by orders of magnitude, even
with mailbox sizes of around 300K emails (20GB), let alone something
like Lucene or Solr.
I understand why it seems like a great idea to store email this way, but
realise that the bulk of email is NOT structured or inherently relational.
=R=
More information about the dovecot
mailing list