To: drums@cs.utk.edu
Subject: Re: PIPELINING
Date: Wed, 6 Mar 1996 15:41:56 +0000
From: Tim Goodwin <tim@pipex.net>
Message-ID: <AAA2KzE9skQAAk+0@pipe.pipex.net>

> >       (1)  require N processes with most existing MTAs,
> >       (2)  require N times the CPU cycles on the server,
> 
> These are _insignificant_.

Uh-huh.  You've never administered a PP system, then.  Each extra SMTP
submission costs me at least *2* extra processes, averaging 2.4M VM and
one SPARC 20 CPU second each; and 2 mkdir, 1 directory rename, and 2
rmdir system calls.  If it's a MIME message going to an X.400 recipient,
you can add another 4 large processes, mkdirs, directory renames, and
rmdirs.

> If you go through your logs you will find that the _maximum possible_
> benefit of multiple RCPTs for your host is under 1% of your CPU time,
> under 1% of your processes, under 1% of your network bandwidth, and

OK, I did that.

Yesterday, one of my relay hosts received 18695 incoming SMTP messages
to 21138 recipients.  Completely ignoring outbound processing, the two
programs associated with message submission used 144.91 and 104.69 CPU
minutes each, for 20739 and 17465 invocations respectively.  The total
CPU time was 758.86 minutes, for 162697 processes.

I conclude that multiple RCPTs saved at least 4% of my CPU time, and at
least 2.9% of my processes.

Sure, PP is almost criminally inefficient (even given the constraints of
RFC 1327), but I assume you didn't intend your sweeping statements to
apply only to well-written MTAs.

I don't have any problem with this paragraph (section 4.6.4.1) as it
stands in smtpupd-01, given the RFC 1123 definition of "SHOULD".

Tim.