piercarl> There is an alternative that is probably the best for large
piercarl> scale sites, and it is zmailer; its macro rewriting language
piercarl> is identical to the shell, and is thus both fiarly legible and
piercarl> familiar, and is much more efficient than either smail or
piercarl> sendmail (it does not fork).
brad> I guess I'm going to have to dig out my archives of
brad> comp.mail.sendmail, because it has been proven in real-world usage that
brad> version 8 sendmail is significantly faster than Zmailer.
We have already gone over this twice over the years, and in both cases I
have explained why the figures you report are erroneous hearsay. However
let's go over it again:
brad> A large University was using Zmailer (certainly an improvement
brad> over IDA sendmail, which is what they'd been using before) and was
brad> bottlenecking at 4000-5000 messages per hour on a 100% busy
Which is impossible because it means that Zmailer takes almost a second
per message _of CPU time_. Now, not even*takes that much to format
brad> Installing version 8.6.12 sendmail immediately caused them to jump
brad> up to 5000-6000 messages per hour and only 1/2 to 2/3 busy.
Which is pretty bad, because it means about one third of a second of CPU
time per message, which is slower than*on a comparable machine :-).
brad> Zmailer was a nice concept, but from what I can tell, it
brad> hasn't kept up.
Uhm I read from the overview in the zmailer source:
zm> - What experience shows that it can do?
zm> Original developement systems had loads of 1000-2000 messages a day
zm> (somewhat more route decissions, like 2-3 times that),
Note _loads_, not peak, and this was many, many years ago.
zm> but multi-router mode has enabled serious processing to happen which
zm> sends out 20-50 THOUSAND messages a day On one burst-load test the
zm> system did show up to handle about 12500 messages a day per router
zm> process (three route lookups on each message from DNS across the
In the case where _all_ messages are offsite. This is a worst case, many
years ago, and does not mean CPU.
zm> If system can take more route processes, it is most likely
zm> possible to increase system performance to hundreds of thousands
zm> messages per day.. There is no conclusive evidence that next
zm> possible bottle-neck, scheduler, won't clog, but there appears to
zm> be ample power (if your host has it..) -- 50 000 messages a day is
zm> no problem. ( Sun SS-10/41 ) [ Apr-1994 ] Another burst-load test
zm> routed 1000 messages to "nobody" (via local alias db to
zm> "/dev/null") on an Sun SS-10/50 MHz/Solaris 2.4, gave speed of 120
zm> 000 messages per day per router process (the test was run with 4
zm> parallel routers) On same machine with scheduler from
zm> zmailer-2.99.15, scheduling the messages took a bit under two
zm> minutes (1:55), which indicates speed of roughly 750 000 messages
zm> per day. Very likely it can exceed million messages per day (not
zm> million recipients, like when expanding lists, but million
zm> individual recipients) [ Aug-1995 ]
So, on a modern machine it does 1,000 local deliveries in 120 seconds,
for a speed of 10,000 messages per hour at 1/3 load.
Presumably this turns into much the same for non local deliveries even
for remote deliveries, if one configures multiple processes (say 3-6) as
one should do, because then DNS lookup waits can be overlapped.