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

[jwh2@cornell.edu (James W. Howell)]

At 02:30 AM 2/24/95 +0200, Matti Aarnio wrote:
>> >  - 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 ?

It seemed to wander between them sometimes.  If you happened to restart when
you had a fairly large queue, then the scheduler queue would be the biggest
problem

>
>> >  - 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.

Sendmail allowed us to split the I/O among multiple paths, we installed a
second Sbus, and basically split the load between the two.  The single
scheduler process also seems to be a bottleneck.  One other thing is that
when a chunk of smtp mailers were started it seemed that nothing else would
be scheduled until all the children finished, this could be a real problem
if one child is waiting for a timeout.  I like the ideas that zmailer has in
regards to the queueing system, but the implementation needs a bit more
work.  Multiple schedulers would be a good start.

>
>	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>
>
>

                                                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