On 26.6.2020 15:20, Wietse Venema wrote:
Patrik Rak:
What about the following solution: introducing per-sender windows,
similar to per-destination windows?
In little more details: nqmgr keeps the list of jobs in FIFO order.
(There is some preemption logic which allows some mail to move towards
the front of the list under some conditions, but fortunately we can
completely ignore that here). The selection of next entry for delivery
is simple in essence, simply traverse this list and return entry of the
first job which is not limited by per-destination delivery windows.
If we added another condition which might prevent the job from being
selected, in this case a per-sender limit, the traversal would simply
continue and next job on the list would be considered.
I believe that is worse than 'classes' or sender round robin:
You artifcially bound the amount of delivery resources for a sender,
even in the absence of any other email mail in the queue that
competes for those resources.
The result is that Postfix holds mail in the queue longer than
necessary, resulting in unnecessary active queue congestion and
slowing down all other deliveries that might arrive.
Classes or sender round-robin will give the sender all resources
in the absence of other mail, so Postfix clears the queue as quickly
as possible while still respection destination concurrency limits.
It's a liveness/utilization isssue. No delivery agent should be
idle when it could deliver mail that satisfies concurrency limits.
It doesn't have to cause underutilization you describe. I have never
said I will limit it in the absence of other senders - I talked about
dynamic limit, which can be definitely designed in a way to prevent
underutilization. For example, the limit can be imposed only if a sender
uses all/most agents while there are enough other senders who get nothing.
OTOH, there is a big problem with round robin. It's a double edged
sword. It can harm you as much as it helps. In your example, you want to
use it so single recipient mail can get ahead of bulk mail. That's good.
But by the same principle it will also cause bulk mail to get ahead of
single recipient mail. That's bad.
Patrik
