Re: Lyris

["John Buckman" <jbuckman @ shelby . com>]

> 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. 

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 

So, you are making a similar claim.  Your rate is 643,500 messages
per hour, while we are claiming half that: 300k/hour. 

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.  Our current delivery numbers are approximations of what we
believe Lyris can do.  We'll have much more accurate numbers in a
few months.

Note, however, that our sending model is _completely_ different from
LISTSERV, ListProc and Majordomo.  Every message which goes out to a
list member is slightly different.  Each message contains the
member's name and ID in the SMTP header, so that if the message
bounces, it is much easier to identify, thanks to SMTP header
information.  

The To: address of every message is always the recipient's email
address, not the list name.  This makes it simple for the recipient
to determine what email address they are subscribed with.  

I don't know of any list server which has these capabilities.  

> 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.

A database and a text file are two completely different things, you
simply cannot compare numbers.  With a text file, you already have
the result set, all you need to do is read it in.  With a database, 
you are specifying what result set you want, and it is dynamically 
created.

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.  

For instance, when someone wants to unsubscribe, you'll first want to 
search the subscriber list for their email address.  If that's not 
there, you'll want to find their firstname/lastname.  Finally, if 
that still doesn't work, you'll want to find all the email addresses 
with the same domain name as them, see if any of those are close 
(perhaps just an added hostname) and make a decision based on that.

For these reasons, and many more, we decided to use a fast database
engine at the core of Lyris.  It was a lot more work than using text
files to store information, but based on the features we wanted to
implement, it was the only way to go.

A few examples:

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 technique effectively gets rid of spam, since spammers
join a mailing list, and send their spam as the 1st post.  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).  

Another example of the advantages of using a database are in reading 
message archives.  On the fly, you can sort messages by topic, by 
author, by date, etc.  You can text search using a word index of the 
messages.

John

john@shelby.com, Shelby Group Ltd., http://www.shelby.com/