Re: Zmailer and other MTAs

[mea@nic.funet.fi]

> 	I would like to know how Zmailer performs when compared to other
> modern fast MTAs such as exim, qmail and smail?

	Its routing facilities are "a bit" too heavy on the need of CPU
	cycles to beat most of the current crop of systems with builtin
	routing algorithms.  The curse of interpreted (though tokenized)
	script languages with lisp-like internal data structures.
	A long-term goal is to speed up the language.

	One of the main goals of the ZMailer design is to provide
	predictable resource usage on system.

	From ZMailer design paradigms follows that it has a minimum
	(average) latency of around 20-30 seconds for a message delivery
	on a LIGHTY LOADED system.

	Latency does not mean lack of throughput, just that different
	parts of the system spend time just sleep()ing every now and
	then before entering a burst of activity.

	The sleeps do not occur, if the system finds more work to do
	when it is looking for new jobs.  Thus a saturated system works
	at full blast until the work-queue (at the routers) is empty.

	If you can't get out as much email as you get in during the same
	time period, then things will look grim for you, but the system
	will not die on it.

> 	I've been using qmail regularly since version 1.00 and I am quite
> satisfied with it as the MTA of my final delivery box (only delivers to
> the machines outside the LAN). However, the different configuration paradigm
> that qmail uses imposes a system impact that many systems can't accept. 
> Besides, qmail innability to deliver multiple recipients emails in a single
> connection is quite annoying when dealing with busy hosts. Nevertheless,
> it is very fast and very reliable. I am satisfied.

	One of the major gripes why I dislike qmail is its style of
	going to "send all messages and recipients at once, as many
	as possible in parallel".  No sending multiple messages in
	the same smtp session at all...

	Meanwhile the style of things in the current ZMailer scheduler
	yields occasional gripes from users too -- for a given target
	domain only ONE thread is executing.  All messages are sent in
	series.  Sometimes people want a degree of parallelism -- like
	sending two streams to the same target, one with messages up to
	some threshold size, another for larger messages.

	In certain cases ZMailer can do tricks where it can beat hands
	down other MTAs when it comes to SMTP delivery speeds, but
	that requires semi-smart remote-end machines (SMTP PIPELINING
	facility is used for a huge advantage.)

	Performance of the scheduler is some 5-10 times that of the
	router.   Loaded system can schedule and deliver messages out
	faster, than it can route them.

> 	Nonetheless, I began trying other MTAs.
> 	I didn't try smail, yet I tried exim that is more or less meant to
> be an improved "version" of smail. It performed with a degree of success.
> However, I didn't like its performance and the relaying control capabilities
> could be polished a little bit.
> 	I didn't try Zmailer yet.
> 	I would like to know how does it perform against qmail. Is it faster?
> qmail claims to perform about 8 times faster than Zmailer.

	qmail has small, VERY SMALL memory working set, while ZMailer
	has far larger (and more ambitious) datastructures to play with.
	It does translate to speed (or apparent lack of it) also.
	Usage of flat/non-flat directories may also affect things at
	UNIX kernel level, which may balance things when comparing
	different systems.

>    Does anybody have
> any information in this issue? And the relaying control capabilities? The
> manual suggests they are up to the job. Did any real life conditions prove
> otherwise?

	Just recently one user had serious problems at relaying control.
	Turns out he had commented off all variants of the default behaviour
	defining entries...  The ultimate default is: all open

> 	I am still using qmail, yet I am with a mission. I am still hunting
> for an MTA. :)
> 
> 	Regards,
> 		Mario Ferreira
> 
> --
> Mario S. F. Ferreira		System Administrator/Consulting @ GNS
> Email(no _s): _L_ioux(at)g_ns.com.br | PGP key & contact info: finger Email

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