[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Wed, 13 Mar 2002 18:51:54 -0500
On Wed, Mar 13, 2002 at 05:59:36PM -0500, xystrus wrote:
> On Mon, Mar 11, 2002 at 11:49:09PM +0000, Nic Ferrier wrote:
> > xystrus <address@hidden> writes:
> > > Well, we discussed this at length on the mutt users list.
> > > Maildir is not without its own problems... It takes
> > > substantially longer to open and index a Maildir/MH folder
> > > than it does to do the same for a MBOX folder.
> > This is an interesting paper about maildir:
> > http://www.courier-mta.org/mbox-vs-maildir/
> Woah Nellie! I just had a look at this, and we're not really
> comparing mbox to Maildir, we're comparing Courier IMAP to
Reviewing the analyses further shows that in many cases where
UW-IMAP falls down, it's the implementation that sucks, not
necessarily the mbox format itself.
One unexpected result is the UW-IMAP server's poor performance
in the SEARCH and FETCH benchmarks. It appears that the server
has some kind of a problem here, scaling to mailboxes that contain
large messages. Note that the UW-IMAP server spends most of its
time in "user" state. There's very little system activity. The
process spent pretty much all of its time in user space, and that
is entirely responsible for its poor performance.
This tends to suggest that the code is working too hard to do
whatever it is that it's doing. With a good implementation on
beefy hardware, the bottlenecks should generally all be I/O
related, not CPU. While not conclusive, this is IMO more evidence
that UW's implementation sucks. I've already long been of that
opinion anyway, as have all of my associates familiar with UW-IMAP.
The phase 1 fetch.1 also shows the performance issue with Maildir I
was talking about -- reading many small files as opposed to 1 large
file. This is typical behavior for when one first logs into the
IMAP server, when their mail client is trying to get an index of
messages to display to the user.
What's not entirely clear here is the effect filesystem cache had
on the benchmark results. Specifically, for the fetch.1 in phase
II on high end hardware, the time seems extremely out of whack. I
suspect that the server still had the entire spool in FS cache
when this test was done, since it certainly had plenty enough memory
for that to be the case. The author does not mention making any
efforts to clear the FS cache, so I suspect he didn't. However,
that case then does not mimic real-world conditions, as a user who
first logs into the server isn't likely to have their mail spool
already in FS cache, unless they were just logged in a moment ago.
As far as I'm concerned, the phase III tests are absolutely worthless,
because no user on the planet has an Inbox with 20 messages of 200K
each. This doesn't reflect real-world mail usage in any way.
These tests are great for comparing Courier to UW-IMAP, but are
anything BUT conclusive comparisons of mbox mail folders vs.
Maildir mail folders.