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.
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...
(grin)
> 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 PROTECTED])
Apple Mail List Gnome (mailto:[EMAIL PROTECTED])
