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

Re: forwarded comment from comp.mail.sendmail on zmailer vs sendmail



James W. Howell wrote:
> At 02:17 AM 2/23/95 -0500, Tom Samplonius wrote:
...
> >  I find this highly dubious, because:
> >
> >  - no mention of Zmailer config:  how many routers?, RAM, etc
> RAM - 80 Meg, Routers 10

	But the queues as seen by the management (and users) were
	not on the routers, I presume ?  ("mailq -ss")  Rather on
	the scheduler ?

> >  - if machine was in "constant I/O wait", doesn't that indicate that 
> >Zmailer had reached hardware limitations and that nothing could do 
> >better?   
> 
> Your right Zmailer had reached its limit on that hardware, but Sendmail on
> that machine was only using half the capacity of the machine to send on
> average 30 percent more mail per hour.  The point is that Sendmail seems to
> be more efficient.

	At FUNET we have a PP running X.400 gatewaying, and it uses
	many of similar processing models as ZMailer.  It is an IO-
	killer too -- or WAS until that machine got installed an
	PrestoServer (the NFS-accelerator), then its throughput
	increased dramatically.   All that just because of massive
	amounts of syncronous disk-writes (directory updates)...

	Now what is so different in between sendmail, and ZMailer
	in this respect ?   Sendmail has two files (?) per message
	all in one directory, while ZMailer has those two too, but
	in a bunch of directories which are constantly being created
	and deleted..  Now THAT is an IO-killer..
	Also while the message is in processing, sendmail does not
	fork and exec a child (well, perhaps "Mlocal" is different?)
	with its own startup pains to do the transport.
	Monolithic approach has its benefits.

	I don't see any good ways out of it, expect keeping all
	messages in one directory (transporter ?) and thus reducing
	the amount of sync-writes.  (Yes, it CAN be done with
	zmailer-2.99.x, because its scheduler uses its internal
	work-database to see, if a filename from readdir() is
	already in works..  The lock-rescanning uses it.)

	Any (other) ideas folks ?

> >Tom
> 
>                                 James W. Howell
> Cornell Information Technologies - Network Resources Collaboration Systems
>                Home Page: <http://lmbass.cit.cornell.edu/>
>                Phone: (607)-255-9369  Email: jwh2@cornell.edu

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