Chuq Von Rospach <email@example.com> wrote:
> At 3:25 PM -0700 10/11/99, Jeremy Blackman wrote:
> > However, one
> > of the problems with Majordomo is also that, for a high-traffic list, it's
> > re-parsing the whole program (which is NOT a trivially-sized Perl script)
> > for each post. Ouchie!
> But compared to the time spent queueing and delivering, it's still
> statistically insignificant. Bulk_mailer or whatever you use as your
> SMTP backend blows the recompilation out fo the water as far as
> overhead, and sendmail blows that out. you can do huge performance
> improvements simply by teaching the backend to directly write
> sendmail Queue files, and that'll buy you more than anything you
> could do to majordomo itself, other than the flat file problem.
It should be noted that all the architectureal shortcomings of
Majordomo 1.x which have been pointed out in this thread so far are
solved in Majordomo 2.
May blessings from the eternal God surprise and overtake you!
Norbert Bollow, Coach http://thinkcoach.com Backup email: firstname.lastname@example.org
> In fact, 95% of my problems are directly related to disk I/O issues
> -- disk I/O delays reading/writing subscriber files on the one side,
> and disk I/O in the sendmail queue(s) on the other side. Running 450
> sendmails at once in a mail queue with a 5,000 or so batches in it --
> you spend a lot of time locked up waiting for the directory inodes to
> free up. I've dealt with the latter, for right now, by simply using a
> ram disk. And the former by replacing the flat files with MySQL. perl
> being an interpretive language impacts the system less than running
> "top" does...
> > Often times, this may be the way to do it. I've found it may be easier to
> > write a custom app than make an existing one do things the way that works
> > best for you.
> Depends on what you're doing. For my Big Honking Listserver, it
> definitely does. For the smaller, more standard server, I want
> something off the shelf, and since I need to either upgrade to
> majordomo II or replace majordomo with something else, I've decided
> it's time to go back to square one and evaluate everything. I like
> the potential of majordomo II, but it just seems like they're trying
> to do things that sympa had months ago. Sympa seems more solid,
> further along the development path, and more solid/proven -- mj2 is
> still really being shaken out.
> (and yes, I'm part of the problem with mj2 -- watching instead of
> helping -- but a person only stretches so far...)
> > (Actually, as far as I'm concerned, all 'general' apps should be easily
> > customizable and extendable - hence Listar's plugin architecture. But
> > that's neither here nor there.)
> don't disagree a bit. A good, solid API is a good thing...
> > I've been a subscriber on lists using both; I tend to prefer Sympa over
> > Mailman because I hate going to a website to tinker with subscription
> > options.
> On the other hand, for the more naive and less-savvy internet users
> that my lists tend to attract, it's a godsend. I can't tell you how
> much mail I get from people who are scared to death by majordomo.
> it's nice to be able to do those things by e-mail, but the web is so
> endemic, I don't worry about that a bit any more. If I can only have
> one interface, I'll take web in a nanosecond.
> Chuq Von Rospach - Plaidworks Consulting (mailto:email@example.com)
> Apple Mail List Gnome (mailto:firstname.lastname@example.org)