Re: tls connection reuse
Viktor Dukhovni: > On Wed, Dec 14, 2022 at 07:17:43PM -0500, Demi Marie Obenour wrote: > > > > None have come up sofar. So maybe it is safe to make it the default. > > > We know it works well for small messages. but I'd like so see > > > performance metrics for large email messages, because many connections > > > are handled by a smaller number of single-threaded tlsproxy > > > processes. > > > > Can these processes handle multiple connections concurrently in an > > event-driven manner? > > Of course, but a single proxy process does not take advantage of > multiple CPUs, and the cryptographic processing, especially of the > initial handshake to set up a new TLS session, is serialised within each > process. This should not be a problem under realistic conditions. > > Bulk encryption also adds some internal latency, but modern CPUs have > hardware accelerated AES that makes this latency largely insignificant > for SMTP. And by design, the number of tlsproxy processes increases as the workload increases, so that multiple CPUs will be used if needed. Wietse
Re: tls connection reuse
On Wed, Dec 14, 2022 at 07:17:43PM -0500, Demi Marie Obenour wrote: > > None have come up sofar. So maybe it is safe to make it the default. > > We know it works well for small messages. but I'd like so see > > performance metrics for large email messages, because many connections > > are handled by a smaller number of single-threaded tlsproxy > > processes. > > Can these processes handle multiple connections concurrently in an > event-driven manner? Of course, but a single proxy process does not take advantage of multiple CPUs, and the cryptographic processing, especially of the initial handshake to set up a new TLS session, is serialised within each process. This should not be a problem under realistic conditions. Bulk encryption also adds some internal latency, but modern CPUs have hardware accelerated AES that makes this latency largely insignificant for SMTP. -- Viktor.
Re: tls connection reuse
On 12/14/22 07:05, Wietse Venema wrote: > Gino Ferguson: >> Hi List, >> >> >> I'm reading the doc and wondering why 'smtp_tls_connection_reuse' >> is not enabled by default? > > Because it was unknown if doing so would cause problems (in Postfix, > or in other software). Only real-world deployment can tell such > things. > >> Are there any possible drawbacks? > > None have come up sofar. So maybe it is safe to make it the default. > We know it works well for small messages. but I'd like so see > performance metrics for large email messages, because many connections > are handled by a smaller number of single-threaded tlsproxy > processes. Can these processes handle multiple connections concurrently in an event-driven manner? -- Sincerely, Demi Marie Obenour (she/her/hers) OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: tls connection reuse
Gino Ferguson: > Hi List, > > > I'm reading the doc and wondering why 'smtp_tls_connection_reuse' > is not enabled by default? Because it was unknown if doing so would cause problems (in Postfix, or in other software). Only real-world deployment can tell such things. > Are there any possible drawbacks? None have come up sofar. So maybe it is safe to make it the default. We know it works well for small messages. but I'd like so see performance metrics for large email messages, because many connections are handled by a smaller number of single-threaded tlsproxy processes. > People from GMail suggested us to enable this feature. > > We're on postfix version 3.4.13-0ubuntu1.2 The implementation has not changed, which is a good sign. Wietse
