On Thu, 08 May 1997 15:14:38 -0400 Brad Knowles <[log in to unmask]> said:
> However, we don't design systems for performance under "average"
>conditions, we design for what we consider acceptable behaviour under
>worst-case conditions.
Who doesn't?
> The work that would be necessary to give you all the various sorts
>of hooks you'd need to filter out the mail we don't want to get, is in
>and of itself sufficient enough to warrant writing a system that would
>obviate the need for yours.
>
> In fact, in the system we are writing from the ground up, that's
>where the bulk of the work is anyway. The part of handling the SMTP
>dialog on non-forking servers, etc... is largely done.
Brad, at some point you're going to have to decide whether you're in
operations and can't speak about development issues, or you're in
development all right. This statement is one that I would expect from the
development manager in charge of deciding how your new mail service is
going to be developed, after having reviewed the potential benefits of
using (among other bidders) LSMTP as an API-driven SMTP engine.
Incidentally, you are going to have to be a lot more convincing if you
want me to believe that "hooks to filter out the mail AOL doesn't want to
get" is the bulk of the development work for AOL's new ground-breaking
mail system, and everything else is puny and trivial.
> If we're going to completely replace it anyway, we might as well do
>the replacement system *right*, so that it doesn't need any kind of a
>"front-end" (replacing a sendmail front-end with an LSMTP front-end is
>essentially a NO-OP).
It might be a no-op development wise, but operationally this is something
that could potentially be deployed very quickly (as quickly as DEC can
deliver hardware to your site, and I'll bet they'd deliver REAL fast once
you explained what it would be for and told them who makes the unix boxes
you're using). You keep telling us that you are having a problem that
threatens the very existence of AOL's delivery service, well, if that's
true I certainly wouldn't use the word "no-op" to refer to a potential
solution to this problem, even if it is a temporary one!
> You've seen the work that Rob Kolstad has done with sendmail, tuning
>it to get multiple millions of mail messages delivered within the period
>of one day, on a Pentium-class machine running BSDI/OS?
No, and I'd be glad to check it out you give me some pointers, however I
assume that it is a special case as there is a very limited number of
sites on the Internet that have millions of real messages to deliver
daily (AOL, CompuServe, Prodigy, L-Soft, CNET on a Thursday if they also
send a special, I think that's it). In order to make this test with live
traffic, you just have to be one of these sites. In a lab environment I
got 600k/hour out of sendmail on an old workstation with about the speed
of a P133. That's without even bothering to tune sendmail. I'm not saying
this is what Rob did, in fact I'm sure his was a much more legitimate
test, I'm just trying to put things in perspective here. Figures based on
lab configurations or short periods of time just don't mean much.
> I think this is a new world-record price/performance point,
Well, LSMTP could deliver 100k messages per hour on a P133 with 64M and
one drive when it was released over a year ago. That's 100k LIVE
recipients from a 15h live test (1.5M deliveries), and tuning was limited
to setting the desired number of concurrent deliveries. Since then we
have made significant performance improvements, although we haven't
re-run the P133 test (we no longer have the P133, or rather, it's sitting
on someone's desk as a Word machine :-) ).
Eric
|
