On Tue, 10 Dec 1996 11:57:05 -0800 (PST) James Cook <jcook@netcom.com>
said:
>the qmail page describes performace differences as follows. But some of
>these seem based on the same tests denounced as "not real world" in
>earlier threads, i.e. on a LAN, etc.??
I think the language in question is mostly trying to establish that
subcomponent XYZ of qmail is n% faster than the corresponding
subcomponent of Zmailer, sendmail, etc. As I read it, there is no claim
that you can get these figures with real world recipients. This is more
of a techie discussion where every part of the respective engines is
compared in turn by isolating it from the others and testing it.
> Mailing lists with remote recipients: qmail uses the same delivery
>strategy that makes LSOFT's LSMTP so fast for outgoing mailing lists
Something must be wrong. Is the qmail page actually saying something
positive about another product? ;-)
> Separate local messages: What LSOFT doesn't tell you about LSMTP is
>how many separate messages it can handle in a day.
Well, since L-Soft has never been asked, it's not really surprising that
we haven't been telling Dan :-) I'm not really sure what is meant here.
One of our internal benchmarks is to dump 1000 separate messages to
LSMTP, with one POP recipient each. This typically results in a rate of
20/sec = 72k/hour on a P100-class machine (this is from memory and
assumes you have a fast enough sender). LSMTP does all sorts of things to
handle large queues with minimal impact. Our main LSMTP server typically
has 25,000-50,000 individual files in its queue on a normal day.
Sometimes it goes over 100,000. We don't have specific figures for
performance as a function of queue size because it doesn't seem to have
been a problem in practice. I suppose we could develop new benchmarks if
needed.
> Overall performance: What really matters is how well qmail performs
>with your mail load.
Again it seems clear to me that there is no attempt to deceive here. The
LAN based figures are just a technical comparison of the internal
mechanisms of various unix-based MTAs.
Eric
|
|
