postfix-devel

Victor Duchovni:
> On Thu, Jun 25, 2009 at 02:45:04PM -0400, Wietse Venema wrote:
> 
> > Victor Duchovni:
> > > On Thu, Jun 25, 2009 at 02:07:46PM -0400, Wietse Venema wrote:
> > > 
> > > > > > Can you quantify the gains, in terms of of long-distance network
> > > > > > roundtrips? Assuming that the DNS lookup is cached on-site, the
> > > > > > gain would be the TCP-level handshake.  What else?
> > > > > 
> > > > > Connection caching is not about saving round-trips, it is about
> > > > > overcoming adverse (orders of magnitude higher) latency when
> > > > > k of N MX hosts are down and non-responsive (30s timeout vs.
> > > > > sub-second TCP 3-way handshake latency when the host is up).
> > > > > 
> > > > > Caching connections allows one to avoid new connection creation, which
> > > > > involves unpredictable latency. The alternative could be a negative
> > > > > cache for dead MX hosts with a life-time comparable to the connection
> > > > > re-use time (300s).
> > > > 
> > > > An alternative is for the scache daemon to have an option to retain
> > > > "these hosts are good" meta-data for a couple seconds. With this,
> > > > the discovery problem is sidestepped, and non-TLS connections may
> > > > benefit, too.
> > > 
> > > The problem with "these hosts are good", is that one does not necessarily
> > > know all the hosts that are good, and don't want to pile all the
> > 
> > But, isn't this exactly how connection caching works? If you can
> > cache connections, then you will be talking again to the same good
> > hosts, all having the same MX preference.
> 
> No, because with connections, there is a finite pool of fds, and when
> all are used concurrently, new connections are made, so the load
> is reasonably distributed in practice.

Nonsense! Descriptor-less cache entries are reference
counted, so if the cached entries have been given out the
SMTP client goes out to disvover a new host that works.

        Wietse