Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Mar 2012 14:45:29 -0600
From:      Mark Felder <feld@feld.me>
To:        freebsd-questions@freebsd.org
Subject:   Re: imap server performance benchmarks
Message-ID:  <op.way2l3g834t2sn@me-pc>
In-Reply-To: <4F5AAB9B.4090007@herveybayaustralia.com.au>
References:  <4F596EA7.4090207@herveybayaustralia.com.au> <20120309194613.GA28476@ayn.mi.celestial.com> <DCE3E9EEF0B744E3866969A59B6A35C9@jenweldandeskt> <op.waxcepd634t2sn@tech304> <4F5AAB9B.4090007@herveybayaustralia.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 09 Mar 2012 19:17:15 -0600, Da Rock =20
<freebsd-questions@herveybayaustralia.com.au> wrote:

> Yes, thats true. That was tested in the paper: a cyrus? using sql =20
> database backend performed faster in searches and lookups. But writing =
=20
> and deleting was a drag, and you lose the shell; but I'm not sure that =
=20
> thats such a problem as one could find tools in the sql commands =20
> (provided you know databases well enough).

Since Archiveopteryx is so tightly integrated with Postgres, this seems =
to =20
be less of a problem.

 From their FAQ[1]:

> Some question about capacity.This question crops up in different =
shapes =20
> =E2=80=94 =E2=80=9Chow many users?=E2=80=9D, =E2=80=9Chow big?=E2=80=9D
> Archiveopteryx's bottleneck is the number of deliveries per minute, =20
> everything else is irrelevant.
> How many messages do you need to inject into the database in the =
busiest =20
> five-minute period of theday? In a business, that's usually in the =20
> morning and immediately after lunch. On fast PC hardware,Archiveopteryx=
 =20
> currently handles in the neighbourhood of 4000 deliveries per minute.

Wayback Machine has this FAQ entry going back to 2007. I'm pretty sure =20
that on current hardware we can do more than 4000 messages per minute.

On the topic of deletes: They're pretty fast in AOX. Deletion is only a =20
flag and a nightly cron does the real purging. You set a retention =
policy =20
=2D- you choose how long the email stays in the DB before it's actually =20
purged. It's pretty slick, and I like setting things like forced =
deletion =20
of all emails in my SPAM folder if they're older than 30 days, and my =20
other mailboxes I can undelete up to 14 days after. It's saved my butt =20
once or twice. I'd love to have this for our customer's email.

The real problem when you start dipping into this type of an environment =
=20
is figuring out how to support it. You're no longer running a mail =
server; =20
you're now a DBA. If I implemented this at work I have three hurdles:

1) Not pissing anyone off when they find out their GPG is broken  (low =20
likelihood, but it's naughty to do this. FYI, they're working on a fix =
but =20
it has significant hurdles.)

2) We're now admins of a 120GB Postgres database. This is a daunting =
task, =20
and the hardware requirements are more than if you were just running =20
Dovecot/Cyrus. (AOX does dedup and my estimate brings this down to =
~100GB, =20
but I don't know how the big indexes will be)

3) Well now we probably want a slave so backups don't lock the tables at =
=20
night....


I absolutely love the idea, but outside of my own email or hosting for a =
=20
friend I don't think it's a feasible solution, which saddens me... a few =
=20
more devs and the project could really shine.


[1] http://archiveopteryx.org/faq/mailstore#capacity



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.way2l3g834t2sn>