On Thursday, January 4, 2001, at 05:56 PM, Cillian Sharkey wrote:
> I recently built IMAPD 2.0.9 + SASL 1.5.24 + Berkeley DB 3.11 from source on
> NetBSD 1.5 release (i386). I use LMTP/TCP delivery with Exim 3.20, pwcheck for
> auth and plaintext over SSL with Netscape 4.75 MUA. Overall, quite impressed!
I also use NetBSD (in fact, all my servers are Sparcs and Alphas running NetBSD). It's
a great operating system, but you'll definitely want a -current kernel with UBC for
your IMAP server. You can run a -current kernel with a 1.5 userland.
> - configure has a problem with NetBSD's mmap() and warns:
> *** This system does not have a working mmap()
> *** Expect a considerable performance penalty
>
> Is this serious? The IMAP system will eventually have ~700 accounts and at
> most 30 simultaneous IMAP sessions, with a 'reasonable' volume of incoming
> mail via lmtpd.
Yes, this makes a *huge* difference. Without shared mmap support, Cyrus must, for any
operation which requires reading any part of a file, read() the *entire* file into
memory. This causes a lot of performance problems, even with a single user on the
system.
Consider a couple common situations. With MUAs such as Outlook Express (which is
inefficient in its IMAP support, but generally works) that fetch the entire headers
section of every mail message just in order to display the mailbox view, the user must
wait until every message in the mailbox is read in its entirety before the first
message can be viewed. And some of these files, if your users are average users, will
be huge. Similarly, just doing a SELECT on a mailbox involves reading entire (possibly
large) files.
With shared mmap available (such as in a UBC kernel), only the headers section of each
file will be paged in. This will generally mean reading in only one or two disk blocks
per message, rather than several kilobytes or even megabytes for the larger messages.
Of course, the best thing would still be if the MUA used the "FETCH ALL" command
instead of fetching the entire headers. Cyrus imapd is quite good about caching the
information that the "ALL" request needs. And that's certainly enough information to
display the summary view of a mailbox. But, sadly, many MUAs choose not to do it this
way. It's probably a vestige of the POP origins of so many "IMAP" MUAs.
I did a number of benchmark-type tests of my IMAP server before and after upgrading to
a UBC kernel and recompiling Cyrus to use shared mmap. Just doing a "SELECT" of
several of my mailboxes (using telnet, to eliminate any MUA oddities) takes roughly
1/8th the time with a UBC kernel that it took with a 1.5 kernel. (I tested mailboxes
containing 91, 4439, and 14184 messages. The smallest gains gains were had with the
smallest mailbox, but the larger mailboxes had roughly the same percentage performance
gain. Since my test involved logging in, selecting the mailbox, and logging out, and
timing the whole operation with the unix "time" command, I suspect that connection
setup and logging in dominated the time for the 91-message mailbox.)
The difference has a *huge* impact on the responsiveness of the server as perceived by
the user.
- Geoff
