On Wed, 27 Nov 1996 20:34:33 +7 John Buckman <jbuckman@shelby.com> said:
>All our tests have been conducted using a Pentium 133, w/64mb of RAM,
>running either Windows NT, OS/2 or Caldera Linux (linux performs about
>30% better, largely because of a strong TCP/IP implementation). On an
>ethernet network, mailing to a limited number of machines (on our
>network), we saw delivery speeds around 300,000 messages per hour. Of
>course, that is an artificial number, because the Internet is not as
>fast as Ethernet, but it gives us an idea of the speed of our mail
>engine.
Actually, this is a completely meaningless number because it does not
exercise the areas of SMTP delivery which are difficult to scale and
implement in an efficient way, and which are your bottlenecks as the
workload increases. The only thing it exercises is the protocol engine,
ie the code that sends a HELO command, waits for the answer, sends MAIL
FROM:, and so forth. This is straightforward code that tends to be
implemented with a similar level of efficiency on most products. There
are only so many ways to format a RCPT TO: line and then send it over the
socket. I wouldn't be surprised to hear that you can get these 300k/hour
using sendmail on the same hardware, if you configured and tuned it for
the task. One of our competitors (now out of the mailing list business)
used to make claims in the 100 messages per second range, and they were
using sendmail. They might have made the numbers up, but they were
serious enough that I think they actually built a setup where they got
these figures, so they wouldn't have to worry about lawsuits from irate
customers. Of course you don't get anywhere near 100/sec with sendmail
with a real workload, so this still gave prospective customers an
inaccurate picture of the true, actual performance they could expect when
purchasing list hosting services from this company.
>On a shared T1, using the Internet, mailing to 3000 people, we reached
>about 100 concurrent sending threads. Lyris memory usage at that point
>was about 5 megs, and the message we were sending was 4k in size. In
>that particular case, we delivered mail (to the Internet, to real
>people), at a rate of 28,000 messages per hour (that's after 100%
>delivery complete).
A rate which you should be able to reach with a properly tuned sendmail
with such a small user base. And which, incidentally, is not "hundreds
per second" but 7.7 per second. Come to think about it, 300k/hour is
83.3/sec. "Hundreds per second" is at least 200/sec or 720k/hour.
>However, those 3000 people represents the largest test we have today
You aren't seriously suggesting that the figures will improve as the
number of users and hosts in your workload increases? :-) 3000 people
should be more than enough hosts to keep your 100 threads busy. That is,
you aren't in a situation where you just don't have enough work to keep
your setup busy. Furthermore, minute and hour rates are completely
different animals. Correct if me if I'm wrong, but what you're telling us
here is that you've made 3000 deliveries in around 6 min 30, which you're
extrapolating to 28,000/hour - right? I wish it worked this way, but it
doesn't. For instance, I run a server that is capable of sustaining
120/sec or more over relatively short periods of time (say 5-10 min),
especially in cases where it gets a single posting to many people at a
time when activity is otherwise low. This is with real world traffic of
course. While this suggests the server can deliver 432k messages an hour,
and while if you run the code for 6 months and you are lucky, you just
*might* find a 60-min interval where you came close to this figure, in
practice, on a normal hour, this machine only does some 210-220k/hour.
For planning purposes, the figure the customers need is the 210-220k/hour
one (and this is the one we advertise for this hardware).
>When we query the database for the email addresses of all the members of
>a 3000 person list, the operation takes less than a second.
Well, "less than a second" to read the recipient lists for a
3000-subscriber list is far from impressive. Any compiled list manager
should be able to do 10-100 times better with a silly plain text file.
"Thousands of transactions per second", in the context in which this
claim is made, suggests that you can process thousands of search requests
per second, which I doubt.
Eric
Follow-Ups:
-
Re: Lyris
From: James Cook <jcook@netcom.com>
|
|
