> i find all of the above claims redolent of marketing department hyperbole.
> i would be interested in complete disclosure (e.g. for claim one are you
> refering to input to an smtp server or real remote host deliveries, what
> sort of platform(s) comprise the testbed, is this a real world test or
> a simulation) regarding the specifics.
Here is some more information on each of these statements.
> Extremely fast built-in mail engine can deliver hundreds of messages
> per second.
We wrote our own mail engine for Lyris, both for sending and
receiving mail. Mail receiving is fairly simple, so I'll concentrate
on mail sending.
The mail engine is built using a technique called multithreading.
This means that instead of launching a separate process (with a
fork), a separate thread of execution is launched, which runs
independently, but uses very little system resources (a separate
stack and local variables). Depending on what operating system you
are running on, you are looking at a 10k-20k overhead per thread,
plus the memory needed to store the message in memory (messages
larger than 10k are spooled to disk). At on overhead of 50k per
message, that would allow you launch 200 simultaneous message
threads using 10 megs of memory.
As you know, the speed of message delivery is largely determined by
the number of concurrent message sending operations you can have
running. That's why, on really big Unix systems, system
administrators are able to get great delivery times with sendmail --
they have the memory and CPU power to launch tons of sendmail
processes. That's also why many people use alternative programs to
sendmail, because those alternatives use less memory (and hopefully
less CPU) and thus can have many more concurrent copies running.
Multithreading is the same technique which allows many Web servers to
be so efficient. Each time someone requests a web page, the web
server launches a thread to take care of the request, and then waits
for the next request. Because each thread takes very little memory,
the web server is able to service more concurrent requests than if it
did not use multithreading.
The downside to our approach is that we are unable to port Lyris to
platforms which do not support multithreading. So, Lyris cannot be
ported to SunOS, SCO, BSDI, freeBSD and a few other Unixes.
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.
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).
However, those 3000 people represents the largest test we have today
-- that's because Lyris is a new program, and hasn't been tested with
really huge lists yet. Because Lyris keeps hourly mail sending
statistics, we'll have more accurate delivery numbers once more
people start using Lyris for large lists.
> Built-in ultra-high-performance database engine provides thousands
> of transactions per second.
We license a well respected C/C++ based database engine, which uses a
FoxPro compatible index and data format. As many articles in the
press can attest, the FoxPro format is extremely fast. Our
benchmarks have clocked speeds of 6,000 new documents created per
second. In more real-life tests, the full text indexing thread
indexes about 30 words per second into the database. That's a
query-read-modify-write-commit series of operations.
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.
The database engine uses row-level locking (it doesn't lock the
entire file) so that each thread can access the database
independently.
> Modern, C++ based multi-threaded design was built with performance
> as the top priority.
Lyris was written completely from scratch in C++. Everything is a
prioritized thread, which makes it very responsive, since
user-interface threads run in the highest priority. Message indexing
happens during idle time, as a lowest priority thread, so it doesn't
get in the way.
Lyris is a single program, and uses, when idle, about 3mb of RAM.
It maintains its own internal RAM, database and disk caches. It uses
a message-based system, so that threads that are not doing anything
consume no CPU time. Everything is self-contained, and no external
programs are launched.
Of course, there are still many performance enhancements we want to
add--but I think that the core we have developed is pretty good.
> i did read your features page which led rather smartly to my
> apparent incredulity.
I hope this message helps address some of your doubts. I invite you
to download a copy (once your platform is supported) and give it a
spin so you can decide for yourself whether you like it or not.
John
john@shelby.com, Shelby Group Ltd., http://www.shelby.com/
|
|
