Viktor Dukhovni:
> > On Jul 31, 2020, at 12:33 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> >> No, you *do not* want to do that. That can increase connection
> >> concurrency beyond your process limit, in the form of idle connections
> >> that have a different nexthop than the one to which you're currently
> >> delivering email.
> >
> > We could fix these excess connections by grouping cached connections
> > by transport, and by evicting a cached connection for some transport
> > if a requested connection for that transport is not found.
> >
> > It's not optimal from a reuse point of view, but it ensures that
> > one transport cannot exceed the number of connections determined
> > by its process limit.
>
> This simple eviction policy may be too aggressive, if two destinations
> are each creating new cached connections, each may evict the cached
> connection(s) for the other.
This depends on the number of destinations and the process limit.
If the process limit is smaller than the number of destinations,
like 1 versus N, then N competing destinations will evict each
other's cached connection with high likelihood. And they should,
to respect the connection concurrency limit.
If the process limit is similar to the number of destinations, then
some connections will be reused. If the process limit is much larger,
then more connection reuse will happen.
Note that Postix reuses connections not only based on destination
name but also based on destination IP address (not sure if that
is still the case with verified TLS). Lookup by IP address improves
reuse when multiple outlook destinations share a pool of MX hosts.
But cache lookup by IP address results in multiple cache queries
per delivery request, and that should not result in multiple cache
evictions per delivery request. Thus, my initial suggestion would
need some refinement.
> There should likely be a configurable per-transport limit on the
> connection cache occupancy, so that eviction only happens when
> the limit is reached. The default limit might be a small multiple
> of the transport destination concurrency, and users can raise or
> lower that as needed on per-transport basis.
Without destructive connection cache lookups, the connection
concurrency can be as large as cache_occupancy_limit + process_limit.
That makes the approach unreliable.
With destructive connection cache lookups, the connection concurrency
is guaranteed no larger than the process limit (a connection is either
reused or it is destroyed before an SMTP client creates a new
connection), and the cache does not need to know about process
limits.
Wietse
