Brad Knowles <brad(_at_)colltech(_dot_)com> writes:
On Tue, Jun 23, 1998 at 11:50:58AM -0300, Alexandre dos Santos wrote:
Procmail is working good on NFS, it finishes quickly. But when
cucipop is put on a NFS client, procmails starts to delay too.
Well, yes. Things slow down if you have contention for locks.
Procmail probably isn't writing to NFS, or if it is, it's
probably not using the same locking mechanism as cucipop.
Unfortunately, each vendor and each program have their own ideas
on how to best do that.
cucipop was written by the author of procmail. Ideally, when you
compile cucipop you edit its config.h to use the locking techniques
that procmail's autoconf process determined for your system(s).
However, even if you didn't do that, cucipop uses the same dotlocking
algorithim as procmail.
Also, keep in mind that any POP3 server will have to copy
the mailbox in order to work on it, and many of them copy the
mailbox to /var/mail/.username (you got it -- creating lots of
NFS writes).
cucipop doesn't use a temporary file: it keeps it all in memory.
On deletes it updates the mailspool in place which should never
_lose_ data, though if the server crashes in the middle of this
you can end up with one or more bogus messages.
...
This is a *real* nightmare when you start talking about
users who select "Leave mail on server" and have multi-megabyte
mailboxes.
Assuming you have enough memory, cucipop should be pretty fast.
I think maybe now you're starting to understand why POP3
really doesn't scale well at all in multi-machine environments
(unless you've cooked up a custom mail store that uses a real
database back-end, like Oracle Parallel Server), with /bin/mail
(or procmail) as a writable interface to this message store and
POP3 and/or IMAP as a readable (and writable) interface to this
same message store. Then you can let the database vendors deal
with the hard data replication and distribution problems.
Otherwise, it's a pain-in-the-ass.
Agreed.
Philip Guenther