[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MTA Evaluation on delivery performance



On Sun, Jun 18, 2000 at 05:45:12PM -0400, Andy Poling wrote:
> On Sun, 18 Jun 2000, XosÉ Vázquez wrote:
> > there are a MTA Evaluation on delivery performance
> > at http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html
> 
> I just looked at it, and I think it instead depicts impact on the local
> network rather than delivery performance.

	I don't think so -- not alone.

> None of the graphs indicate how efficient/successful the MTA's were - just
> how many DNS queries they made and how often they initiated and shutdown SMTP
> sessions.
> For instance, ZMAILER's low SMTP numbers on the second and third evaluations
> indicate that it was more efficient, using already open SMTP sessions, etc.

	Sorry, I don't see any lower SMTP connection numbers there.
	All three runs are fairly much separate (a day, or more), so
	that no left-over connections are likely to exist.

> I would have liked to have seen numbers like how many msgs were delivered per
> second, or something similar....

	That test was somewhat skewed in that regard.
	One message for each  <nobody@SOMEDOMAIN>  address.

	Running e.g. 100 messages for each address would have given
	a lot more interesting results in delivery speed scale.

	Reading the graphs, it is clear that SMAIL/EXIM and SMTPfeed
	are using DNS response additional section data, so that they
	don't need to do as much DNS lookups as all others are doing.

	I have thought of doing that, but it hasn't been of any priority.

	What the graphs do show is that there exists a 10-30 second delay in
	the ZMailer from the first DNS lookups to actual active processing.
	(Due to the directory scanning, and job assimilation delays.)

	Other systems are more monolithic, and get "kicked" along quicker.

	MX service pooling ("SMTP Pickyback") is also apparently interesting
	feature in that test.  Due to the ways how ZMailer handles queues,
	it runs all target domains separate, and thus picking into delivery
	all target domains whose MXes point to same system is not quite so
	simple.

	Total runtime of ZMailer at delivery tests was fairly high,
	roughly twice to that of the others (and 3x of qmail).
	Some leftover tails kept lingering around for quite a while.
	The time (and slope speed) of the initial raising slope is
	more informative, but I do feel that it tells more of ZMailer's
	resource sparing defaults than of anything else.

	Doing some magic "bind multiple domains into same thread" could
	be implemented into the scheduler, but to do it, one whould have
	to have some way to correlate DNS entries of destination domains
	into one at the Scheduler.  ... Which violates current abstraction
	division premisses of Scheduler vs. Transport Agents.

> -Andy

-- 
/Matti Aarnio	<mea@nic.funet.fi>