some things can be assessed via tests in the lab. eric t. recently reported
a sendmail test that could deliver 600,00 messages an hour. that's not
a real world test because sendmail normally doesn't get input data that
way, it responds poorly to a growing queue and it often serializes behind
a slow host.
if you set up a test bed carefully it can be used to estimate behaviour
ratios in the real world. if i run a good test of product a and product
b on a fibre ring and a is 100 times faster than b it will likely be true
that a will be faster than b in the real world too. if i just cobble up
some script and say look, i got product a to deliver a million messages
in an hour it doesn't mean anything.
all of dan's tests reveal something important about qmail. several are
related to *local* delivery which has not (quite reasonably i think)
been discussed here. what matters to the person delivering remote mail
is mta latency. how long from when a message enters the delivery queue
until the remote host says ok. the only way to reduce latency is with
parallel delivery. sendmail does this badly for two reasons. one) it
doesn't like to and two) the image is large (compared to something like
the qmail delivery agent).
here's a test: create a queue of 50,000 messages to 500,000 recipients
on at least 100 hosts (they can be on the same network but at least
two should be connected via a sub-rate link, say 28kbps). the number
of recipients should be random per message. start sendmail and see how
long it takes to complete the final delivery. repeat with qmail, exim,
lsmtp and pmdf.
-------- In reply to:
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.??
---------------------
--
paul
References:
|
|
