> On Aug 31, 2019, at 7:52 AM, Jasen Betts via Exim-users <exim-users@???> wrote:
>
> Interpreted code is abot 100 times slower than native code, but disk is
> about 100 times slower than memory, and WAN is about 100 times slower than
> disk. what's the hurry?
It is not the CPU cost of the MTA's code that determines
performance (throughput and latency characteristics under
load).
For a mostly "inbound" MTA, that does content filtering
(anti-spam/anti-virus), performance is dominated by the
CPU cost of the content filters, not of the core MTA.
For an "outbound" MTA, performance is determined by its
ability to sensibly schedule *concurrent* deliveries,
without overwhelming downstream receivers. Here the
rule of thumb is:
Throughput = Concurrency / Latency
And for any downstream destination the steady-state
throughput needs to exceed the message input rate
for that same destination, otherwise the backlog
grows without bound.
At peak loads, moving lots of mail between nearby
systems (high volume internal mail flows) one might
see some differences in throughput from the efficiency
of the MTA. Here re-use of processes (rather than
fork/exec per message), efficient use of the filesystem
(minimizing, especially synchronous, writes to the queue
file), ... also come into play.
For most users of SOHO systems, MTA performance is not
a major deciding factor, they go with what they're
familiar with, or is recommended by someone willing
to lend a hand...
--
Viktor.
