[geeks] thoughts on SMTP

[Greg A. Woods]

I just ran a quick awk job over yesterday's mailer log on a client's
machine.  It reported that in the past 24hrs their machine handled 39k
e-mail messages for a total of ~1.8GB of SMTP in one direction or
another (that's weekend, typically lower, traffic!).

The users accessed the locally delivered portion of that e-mail from
over 9,000 mailboxes which were read regularly (sometimes every 5
minutes by lame-brained lusers, for a total of over 100k transactions)
via POP (through Cyrus).

At the same time it also pushed out several hundred MB of HTTP traffic
(144k HTTP transactions) from Apache.

There were also quite a few FTP logins and transfers too.

That machine is an aging 300MHz P-II/300 with about 512MB of RAM and
some aging 9GB SCSI 7200rpm drives.  (no screaming demon by any standards)

It has more than enough CPU left over to compress all it's SMTP traffic.

(I know this because it runs rc5des to soak up all its spare cycles, and
it runs at about 50% CPU even during peak periods!)

It even does software-level striping of a filesystem over three drives
(but it does not do any parity calculations -- just the CCD driver)

With hardware RAID and a bit more RAM I expect that machine to serve
twice as many customers before HTTP and SMTP have to be split onto
separate machines or moved to a faster machine, and even with three
times the e-mail throughput compression of all SMTP would still be
a reasonable expectation.

So, tell me again why big SMTP servers don't have enough CPU for compression?

-- 
								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>