On Thu, 28 Nov 1996 10:49:30 +7 John Buckman <jbuckman@shelby.com> said:
>If I may quote from an L-Soft press release:
>
>> The total number of subscribers at the site as of September
>> 10th, 1996 was over 985,000 (for all 36 lists). Typically, 98% of
>> the CNET Digital Dispatch subscribers receive their copy in less
>> than 1 1/2 hours.
>
>If we crunch the numbers on this statement, we get:
>985,000 * .98 delivery = 965,300 messages delivered
>965,300 messages delivered in 90 minutes = 10,725 messages per minute
>10,725 messages per minute = 178 messages per second
The exact figures do not affect the point you are trying to make, but
just to set the record straight, the claim is that "the CNET Digital
Dispatch subscribers" have the quoted delivery times. This is excerpted
from a press release that says the CNET Digital dispatch is the first
list to break the half million subscriber mark, or something along these
lines. As noted there were a total of 985k subscribers spread across 36
lists (now 1.25M and 41), but the delivery times are for the 500k list,
ie 90 deliveries per second or 324k/hour.
>So, you are making a similar claim.
I think we have a misunderstanding here. I have never claimed that very
high delivery rates are not possible, or that people who make such claims
are necessarily a bunch of crooks. The figures in the press release you
refer to do not come from a lab test, but from a real world, production
mailing with what I believe is the largest mailing list in the Internet,
and thus the most stressing real world test one could design for the
software (bounces are processed while the messages are being delivered,
yes on the same machine, and I'll let you imagine how many there are).
This all ran on a P166. Finally, the figures were provided by the
customer, not by L-Soft. The gist of this claim is that if a customer
orders the same hardware and software configuration that CNET uses for
the Digital Dispatch, this customer can reasonably expect to get the same
90 deliveries per second. In other words, the numbers are for real.
>Your rate is 643,500 messages per hour, while we are claiming half that:
>300k/hour.
I'm not sure I understand what you're trying to say here. L-Soft makes
the claims that it makes based on the real world results that its
customers get with L-Soft software. I don't see how the existence of a
L-Soft claim in the 643k/hour range would make your 300k/hour claim
legitimate. Your claims should stand on their own merits, not based on
what other vendors have achieved.
My point, again, is that your blurb is claiming:
"Extremely fast built-in mail engine can deliver hundreds of messages per
second"
Then when someone on this list challenged your claim, you reported that
your best lab figures were 83/sec and your best real world figures were
7/sec. There's quite a big gap here. Normally one doesn't publish
performance results until one has actually measured the figures in
question.
>Lyris is a new product, LISTSERV has been around ages. In the mail
>mailing world, Eric has the advantage of years of statistics sending
>mail.
If you meant "years of experience", I can see your point. But "years of
statistics" are totally useless. Given the rate at which the Internet is
expanding, the record numbers are always recent.
Anyway, with 3000 subscribers you have more than enough traffic to reach
delivery rates of at least 50-100/sec. There is no theoretical reason why
you cannot achieve a higher speed than 7/sec. Since each of your messages
is different and requires a separate SMTP transaction anyway, you can
deliver all 3000 in parallel, which is more than enough concurrency to
reach VERY HIGH delivery rates.
>I don't know of any list server which has these capabilities.
If you mean the ability to suppress delivery errors, LISTSERV can do
that, although it's not done the same way. You'll understand the problems
with your approach soon enough :-) LISTSERV has been able to put the
recipient's address in the "To:" field from day one, although most people
don't do that, and again you will soon understand why.
>A database and a text file are two completely different things, you
>simply cannot compare numbers.
If the numbers are for a paper for "Data Processing Concepts 101", maybe
I can't, because the teacher will think I got it all wrong. But if I'm
buying a piece of software that uses a database to perform a very
specific function, I can certainly compare numbers. The only thing I care
about is how fast the product is at doing the various things I bought it
for. I can compare figures like time to read the entire address list,
time to add or delete a subscriber, time for a wildcard delete, and so
forth.
>With a database, I'm able to query the database of subscribers, and
>return it in sorted order by domain name (which speeds up mail
>sending), by first name, by email address, etc. These are all useful
>operations, and that's where a database is handy.
If you mean it saves you coding work, you're right. If you mean it
increases performance, a custom optimized sort would be faster.
>Lyris allows you to set the number of moderated messages per user.
>For instance, you can set your list up so that new members to a list
>need to have their first posting to the list approved by the
>moderator. Once that message is approved, that person is free to
>post.
This doesn't require a database, just support for per-subscriber
attributes. This can be done with a text file, see ListProc.
>Another use: if a member is not behaving themselves, you target them for
>moderating, and say that the next 5 postings from them need to be
>approved (but noone else on the lists needs approval).
Same. Note that I don't have any problem with your decision to use a
database for your subscriber list. You're free to design as you wish. I
was just commenting that "3000 subscribers loaded in less than a second"
is totally unimpressive. "Thousands of transactions per second" certainly
sounds more impressive, but that is because it suggests thousands of
mailing list management operations per second, not thousands of internal
database operations per second.
Eric
|
|
