On Thu, Feb 28, 2013 at 01:16:26PM +0100, Thorsten Glaser wrote:
> > Connection caching has nothing to do with concurrency. Sheesh.
>
> I was assuming that, when you already have a connection to a
> receiving MX, you'd not open another one but reuse the existing
> one, so it would, of course, have something to do with that.
>
> If not? well, that's the qmail model.
One can't immediately re-use an existing connection when some other
process is currently using it! To do that, one would have to always
wait for the other process to relinquish the connection, which forces
concurrency <= 1. This has nothing to do with qmail, which uses a
recipient limit of 1 which leads to more deliveries with multi-recipient
messages than with Postfix or Sendmail.
Postfix reuses *idle* existing connections, but creates new ones
in *parallel* up to the concurrency limit to avoid severely limiting
throughput to destinations with high capacity in the face of high
single message delivery latency.
Sendmail has no concurrency limits at all, since each process runs
in isolation (no queue-manager), it just hiccups at random
when the CPU load is high, which is not a meaningful signal that
the MTA should pause deliveries or refuse new connections.
You mentioned a Sendmail QueueLA or RefuseLA of 8, this is a meagerly
limit on modern multi-cpu server hardware. ~10 years ago, I was
tuning multi-CPU Sendmail servers of that era with a QueueLA of 64.
> > I welcome you to propose a design that is as scalable as the rest
>
> I am *not* interested in Postfix. I'm not even primarily
> working with Postfix.
You're also not interested in any form of critical thinking before
you spout non sequiturs, or even a modicum of humility which would
suggest asking how to improve latency in your two MTA setup, nor do
you care to do any research, rather you barge in here in response to
an 11-year old post blaming Postfix for Sendmail design flaws.
I smell a troll, please don't come back.
--
Viktor.
