[geeks] thoughts on SMTP

Greg A. Woods woods at weird.com
Sun Mar 24 17:12:37 CST 2002


[ On Sunday, March 24, 2002 at 13:54:30 (-0800), David Passmore wrote: ]
> Subject: Re: [geeks] thoughts on SMTP
>
> You really need to stop posting about stuff you don't know anything about.

Ah, excuse me -- I wouldn't have posted anything if I didn't know what I
was talking about.  I've designed and built mail servers engineered to
handle hundreds of thousands of mailboxes on a single machine (that's
one hell of a lot smaller and slower than any E10K).  I've implemented
compression and de-compression algorithms in real-world code that's been
used in production.  I've implemented SMTP protocol code from scratch
and I currently maintain a full SMTP mailer.  I've just posted concrete
numbers from a real-world server that's doing a heck of a lot more than
just e-mail and still has ample cycles in its aging CPU to spare.  I
know _exactly_ what I'm talking about in this case.

> Saying you can't push a machine to max CPU utilization with an e-mail server
> application is just damned stupid. You can push any box to max CPU if you
> have enough load. Trust me, given enough users you'll hammer even an E10k to
> its knees. You've just never dealt with volume that large.

You're obviously trolling here.

We're not talking about any random "e-mail server application" here, and
we're not talking about any random "load'.

Even if you modified a mailer such that the messages never hit the disk
(strictly illegal in SMTP -- the "store" part is a fundamental
requirement of the protocol), and you had multiple gigabit interfaces,
and enough large mailing lists and incoming e-mail to completely fill
theose gigabit interfaces with SMTP traffic, there's no way in hell you
could ever keep an E10K's CPUs pegged without doing a _LOT_ of something
else.

An E10K even in the minimal configuration sold by Sun has more than
enough CPU to compress or decompress all possible SMTP streams you could
possibly ever hit it with or generate from it over any reasonable
high-end Internet connection (eg. 100base-T/FDX Etherent) (assuming you
used a semi-sane compression algorithm and implemented it in some
compiled language for which you have a decent compiler, of course).  A
64-CPU E10K would likely handle multiple gigabit interfaces full of SMTP
with no sweat.

I suppose if you had some very inexperienced programmer implement the
whole mess in interpreted Java then you'd be sunk, but then again we're
talking about real-world high-end MTA servers here, not some high school
project.

If you do something else on the box at the same time then that's your
problem -- and bad mail server design (something we are explicitly _not_
talking about here!).

(that still doesn't mean I think it's worth anyone's effort to try to
implement compressed SMTP streams -- there's no significant advantage to
anyone running the core mail servers whom you'd have to convice to work
with you if you ever wanted to negotiate any noticable number of
compressed streams and make any dent in your own bandwith)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>



More information about the geeks mailing list