[first let me say that the 30-day m.b.g. doesn't mean anything to me and i
don't think it's helpful when you get serious. seems like more marketing
noise.]
the only way to test real-world performance is to run things in the real
world. this is somewhere between really hard and impossible. how does
lsoft do it? they run the largest public mail server in the world. they
might even make money doing it but it would be worth it to them if they did
it for free because if the code works for them it will work for almost
anyone.
i suspect that if you're in the 10k delivery range it doesn't matter what
you use, if you're in the 100k range any decent system (something smarter
than majordomo) should do. around 500k things start to get ugly if you
want to deliver ~75% of your traffic in less than 30 minutes. of course
this is just a single metric. other things matter even more than delivery.
say you have a list with 500k members. how long does it take to update
that list? how long does it take to go from a message in to all messages
out (to the smtp engine)? what happens if you lose power just as you start
to deliver 60k messages? what happens when you can't talk to a major
message sink (say the site AOL or the network MCI) for 36 hours? what
happens when your persistent queue (mail that will ultimately be returned
to the sender) always has 150k messages in it?
-------- In reply to:
This thread on Lyris architecture and performance is educational in my
view. I appreciate the detailed look.
It would also be helpful to suggest *meaningful* methods of testing or
evaluating *real world* performance of listservers.
---------------------
--
paul
pjg@acsu.Buffalo.EDU |public keys at:
pjg@ubvm | http://urth.acsu.Buffalo.EDU/~pjg/key.html
if the above contains opinions they are mine unless marked otherwise.
References:
-
Re: Lyris
From: James Cook <jcook@netcom.com>
|
|
