Micah Thompson asked about ways to speed up distribution of his wx alert list:

> Is majordomo  the way to go with this, or should I look into something 
> like listserv?  Oh, the mailing list must run on an already heavily 
> loaded server which is usually straining to handle all the web traffic 
> being generated by the bad weather (people looking at my online doppler 
> radar). :)


The list-admin FAQ at
ftp://ftp.uu.net/usenet/news.answers/mail/list-admin/software-faq
appears to answer your question.  Here's an excerpt from the relevant
section:

---------------------------------------------------------------
Subject: 2.05  Performance and system-load issues related to mail deliver

The main issue in distributing to large lists is, how quickly can you get the
mail out?  Most MLM's leave routing and optimization decisions up to the MTA
(Mail Transport Agent, usually Sendmail under Unix), but some other systems
-- notably ListProc, LISTSERV, and SmartList -- take a more active approach
in managing network load.  To illustrate, let's look at the path mail takes
to delivery in each of these four systems.
---------------------------------------------------------------

Your technique of organizing recipients by domain and starting multiple
sendmail processes is similar to what Listproc and SmartList (part of
procmail) do.

I've used Listproc, majordomo, and procmail; I'm not all that familiar
with Listserv other than being on some lists served by Listserv.
You'll want to read the FAQ for details, but from what I understand all
Listserv servers cooperate with one another and list mail is
distributed to other listserv servers for further distribution (if my
explanation is messed up somebody please correct me).

A few things to consider:

1)  Use exploders.  For example, if you have several subscribers at
foo.com, send one message to an alias at foo.com, and let the MTA there
handle distribution to multiple users @ foo.com.  This requires the
cooperation of the admin at foo.com, of course.

2) sendmail isn't exactly the quickest MTA in the world.  Look at some
of the alternative MTAs.

3) The time it takes to deliver a message is affected by factors other
than the time it takes to leave your system.  Your network connectivity
can be a BIG factor if you have a large list, especially if you have a
popular web server.  I'm on the the tornado warning list hosted at the
University of Illinois.  It typically takes three or four minutes for a
notice to get to me once it has left the UofI then through Chicago,
mae-west, PSI.NET, and finally to my desktop.

4) Check your network connectivity with your upstream, ALTER.NET.  I
hear UUNET does things like sell you a T1, then overload it by sticking
three other customers on the same T1.  The small print will let you
know what kind of bandwidth you have.  IANAL and other disclaimers
apply.

5) Does Austin have some sort of local NAP, and does your provider
participate in it?  That can also help in distribution to local
customers.

> If the weather warning expires at 3:30pm, and a subscriber doesn't 
> receive it until 4:30pm, they tend to get irrate.  ;)

If they require some sort of real-time notification, well, they need to
understand that email is not a reliable method of notification.

Richard Masoner
Champaign Illinois USA

Reply via email to