Le 18/03/2018 à 19:23, Viktor Dukhovni a écrit :
On Mar 18, 2018, at 1:55 PM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote:
* Caching open TLS connections in the smtp(8) delivery agent for
reuse by scheduling repeated deliveries to the same delivery
agent runs into complex scheduling difficulties. The presence
of open connections don't, and should not IMHO alter scheduler
priority. Messages should still leave in approximately FIFO
order (subject to (n)qmgr's periodic preemption of messages that
split into many envelopes).
I believe routing multiple messages for the same destination through an
array of currently open connections (held by different processes) should
not be slower than opening new connection for each message.
This would be a rather non-trivial effort. And downstream MTAs
at major providers seem to frown on connection re-use these days.
is there an evidence about this?
While traffic to smaller destinations is typically less
performance-critical. So while having TLS connection caching
would be nice, it is not clear that it is a high priority given
the high cost and possibly only moderate benefit.
that is imho still the question. But I'm more curious about questions above
Sorry, no cycles to dissect this point by point. My view is as stated in
the previous message:
* I believe that support for this requires proxy processes to handle TLS
on behalf of (multiple) SMTP delivery agents. The connection cache
would then hold a connection to the proxy, rather than a connection to
the remote destination.
* The feature is attractive, but not urgently compelling. It is complex
to implement, so I cannot predict when work in that direction might begin.
Ok, this is for the connection reuse in the traditional postfix
sense.Some "opportunistic" reuse.
But would it be difficult to implement something for the case when the
connection reuse could be planned by the scheduler before submission to
the agents ?
The most problematic case (and the case for which we would gain a lot)
is when we cross by a factor the transport_destination_concurrency_limit
of mail waiting to be delivered to a destination in the mailq.
In this case, instead of pushing/notifying smtp one mail at time, could
the notifying scheme be extended to be able to push a list of mail to be
processed by one smtp agent ?
With purely static parameters (crossing factor and fixed queue length)
it could be a huge step forward for the most common case, even with low
queue length and could be later enhanced if wanted (dynamic or adaptive
queue length for example).
In my case, I already have transport_destination_concurrency_limit=1 for
the problematic destinations and many parallels servers with their own
public IP. At the scale of my country, the problematic destination is
like google or yahoo for the world. Without connection reuse for
lowering my tcp connexion rate, my servers are always throttled
(temporary blacklisted).
Now my only option would be to disable TLS for these domains, but my
client will put me on fire or more in that case |-)).
Is there any document that describe how interprocess notification is
done in postfix ? More precisely the scheduler -> delivery agent
notification ?
---
Emmanuel.
