Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Subject: Re: Queue only + cache flushing?
From: Brad Knowles (blkskynet.be)
Date: Tue Feb 15 2000 - 05:39:17 CST

At 1:30 PM -0500 2000/2/14, Wietse Venema wrote:

> Connection cacheing is important for single-threaded MTAs such as
> sendmail that make connections one by one.

        There are still significant connection set up delays that could
be avoided, if postfix were able to take advantage of connection

> Postfix uses parallel delivery. When delivering multiple messages
> to the same host, Postfix does not suffer from the connection setup
> delays that sendmail suffers from.

        There are certain minimal TCP connection set up delays that any
application will face. I believe that you found these to cause a
minimal start-to-finish delay of something like 40ms to deliver one
mail message on a local high-speed dedicated LAN, which places an
upper limit on the number of mail messages that can be delivered by a
single-threaded delivery agent.

        But if you can avoid those TCP connection set up delays by taking
advantage of connection caching, you should be able to get even more
messages transmitted per unit of time.

        Out of curiosity, what connection setup delays does sendmail have
with regards to sending a single mail message that posftix does not?

> Postfix ESMTP command pipelining saves more packets than SMTP
> connection cacheing, especially with multi-recipient mail.

        It may save more packets, but TCP being a stateful protocol
requires a certain lock-step method of setting up and tearing down
connections (you can think of these as synchronous meta-data
operations), and therefore there is an absolute minimum required
latency to create a single connection, a latency which I do not
believe necessarily has to be applied to every single mail message

        While a minimum 40ms delay for each and every message sent
(because of TCP overhead) may not be a whole lot when you're talking
about delivering mail to sites around the world where you may have
packet RTTs of hundreds of milliseconds, when compared to delivering
packets locally on a high-speed and relatively lightly loaded network
that has typical RTTs of ~1ms or less, I think this becomes a pretty
significant factor.

> Sounds like a configuration problem. Crank up the concurrency:
> initial destination concurrency some huge number and zero smtp
> destination concurrency limit.

        Can you configure this on a per-domain basis, so that clients
with poor mail servers get a low number of simultaneous connections,
while mail from our internal mail relays that is going to our own
internal high-speed/high-capacity machines would get a higher number
of simultaneous connections?

> Postfix smtp clients are allocated as they become available.
> Connection cacheing helps only when most mail is destined for one
> and the same server.

        This is precisely what happens quite frequently on our internal
network. Like most larger sites, the majority of our users send mail
to other users on the same system(s), and a smaller percentage of
mail is sent to sites outside of our network.

        I believe that connection caching could be a very large benefit
in our case.

   These are my opinions and should not be taken as official Skynet policy
|o| Brad Knowles, <blkskynet.be>                 Belgacom Skynet NV/SA |o|
|o| Systems Architect, Mail/News/FTP/Proxy Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.13.11/726.93.11          B-1140 Brussels       |o|
|o| http://www.skynet.be                          Belgium               |o|
     Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
      Unix is very user-friendly.  It's just picky who its friends are.