Your message dated: Thu, 08 May 1997 19:50:42 +0200
> The total number of SMTP connections I receive per day is limited by the
> intrinsic nature of my workload and not by the capacity of the server.
This is also our situation, when the whole mail system works as
it should. At those times, our machines are pretty much loafing
along, even when they're delivering the full pace of 5 million
envelopes per day to 20 million plus recipients per day.
However, we don't design systems for performance under "average"
conditions, we design for what we consider acceptable behaviour
under worst-case conditions.
By that measure, we're not done yet. In fact, I don't think
we'll ever be satisifed with how our mail system performs, because
as soon as we've reached one performance goal, we set the bar that
much higher again.
> We can look into that as well if it makes sense (I just don't have the
> information to have an opinion on whether it does or not), but to
> clarify, this is not what I was proposing. I was thinking along the lines
> of having LSMTP front end your existing system.
We're completely replacing the current system, so it makes no
sense to front-end one or the other. Whatever replacement system we
get, is a replacement system we get, whether it be based on sendmail,
LSMTP, or entirely written from the ground-up by in-house personnel.
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.
> This is clearly not the perfect
> solution, but my goal was to minimize the amount of development work on
> AOL's side. Basically, you don't need any new code at all, just a small
> sendmail.cf change.
That's not what we're looking for. We recognize the fact that
having a large process sitting on port 25 and doing a fork/exec is
extremely inefficient in our case, and that we need to completely
replace sendmail in that situation.
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).
> Nevertheless, it did scale to 1.1M daily
> deliveries (highest recorded figure). The VM SMTP is not implemented very
> efficiently but is remarkably scalable, given the workloads that were
> actually being processed at the time it was developed.
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?
I don't think it was on mail from mailing lists, either.....
I think this is a new world-record price/performance point,
and with the worlds most common SMTP MTA, to boot.
However, this is an issue for discussion somewhere else, not
on these lists.
--
Brad Knowles MIME/PGP: [log in to unmask]
Senior Unix Administrator <http://www.his.com/~brad/>
<http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0xE38CCEF1>
|
