[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
> 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 ?
> James W. Howell
> Cornell Information Technologies - Network Resources Collaboration Systems
> Home Page: <http://lmbass.cit.cornell.edu/>
> Phone: (607)-255-9369 Email: email@example.com
/Matti Aarnio <firstname.lastname@example.org>