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