On Wed, Aug 02, 2017 at 09:57:43AM -0700, mark burdett wrote:
> > Increased latency can be amortized with increased concurrency.
> > Just open more connections and the overall throughput rate will
> > remain the same.
> >
> > Throughput = Concurrency / Latency
>
> That's true, as a work-around. Unfortunately we're talking about not just
> opening a new TCP connection but also reestablishing TLS, which means yet
> more RTT and CPU. So the increased concurrency will be significant and will
> require upping limits on the client and server side.
Yes, instead of the default destination concurrency limit of 20,
you'll need a limit of 50 or 100, but this should not be prohibitive.
With TLS session caching (ideally the upstream relay supports TLS
session resumption) the TLS handshake can be quite lightweight and
the total CPU is about the same, determined largely by the cost of
encrypting the message payload. So for a given throughput the CPU
is the same, with the extra concurrency just amortizing latency,
with little impact on CPU.
Of course if the other end does not support TLS session resumption
there will be some extra CPU overhead, but modern CPUs are plenty
fast, and can do thousands of RSA handshakes per second.
> I'm guessing most folks in this scenario will prefer to code a lightweight
> SMTP worker that can reuse connections, running at a lower concurrency.
Your call.
--
Viktor.
