On Fri, May 10, 2024 at 01:13:06PM -0400, Wietse Venema via Postfix-users wrote:
> > Logs:
> > grep relay=nlp[123456].*status=sent /var/log/maillog | sed
> > 's/.*relay=//' | sed 's/,.*//' | sort | uniq -c
This fails to deduplicate multi-recipient deliveries, which record
the same relay= for each message recipient. It also does not
distinguish between original connections and connection reuse.
> > 5770 [23]nlp1.loc-prd.net[10.56.155.14]:25
> > 5694 [24]nlp2.loc-prd.net[10.32.32.103]:25
> > 5402 [25]nlp4.loc-prd.net[10.32.32.104]:25
> > 21531 [26]nlp3.loc-prd.net[10.26.15.31]:25
> > 5570 [27]nlp6.loc-prd.net[10.26.15.32]:25
> > 5694 [28]nlp5.loc-prd.net[10.26.15.34]:25
The OP's original post included:
smtp_connection_cache_on_demand = yes
A subsequent post did not. With the configuration in flux, the
measurements are likely to present an inconsistent view.
Note also, that with connection connection caching, the *fastest*
(lowest-latency) server will handle more of the traffic, because its
connection is returned to the "connection pool" more frequently. This
is a *feature*, you want to avoid slow servers so that slow servers
don't impact throughput. Otherwise, the slow servers can become
connection *attractors* tying up all available connection slots.
Clearly round-robit is happening, and the observed fairness anomaly
is almost certainly not due to lack of randomisation, but rather
a result of measurement methodology and/or connection caching.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
