> On Aug 25, 2017, at 5:24 AM, Deniss <lists+post...@sad.lv> wrote:
>
> I have postfix as frontend to absorb incoming messages as fast as possible.
> Then I have slow smtp backend.
> Postfix limits delivery to backend with
> smtp_destination_concurrency_limit = 2
> This works pretty fine allowing to not oveload backend on peaks -
> messages become queued at frontend and delivered with some delay to backend.
>
> But now I want to deliver certain domain with no delay.
>
> Is it possible to catch the sender's domain with restriction classes of
> postfix and pass a message to dedicated smtp process where
> smtp_destination_concurrency_limit is not limited ?
For messages in the active queue the queue manager fairness
strategy for messages that share a common transport is
FIFO with intermittent preëmption (messages with many
recipients are periodically preëmpted by later messages
with fewer recipients). At a higher level message delivery
across transports is round-robin.
So you can make "high-priority lanes" in the active queue,
by segregating a small portion of the traffic onto a separate
transport, with sufficient concurrency to handle that load
without delays at the expected peak loads.
> May be there is way to force qmgr to select messages
> from the domain in first place when it takes messages
> from queue for delivery?
However that strategy only works so long as the active
queue is not full. That is, so long as the active queue
can fully absorb any sustained peak loads in the "low
priority" traffic. If you have sufficient RAM to hold,
say, a million message envelopes in memory (if that's
the expected volume of your message buffer bloat for
the slow destination) then size the "active" queue
accordingly, and keep your "incoming" queue essentially
empty at all times.
The queue manager does not know what's the "incoming"
queue, those are just files on disk. That's how the
queue manager manages to run in bounded memory. So
prioritized scheduling (multiple lanes at the airport)
only works while the incoming queue (road to the airport)
is drained promptly and is not congested.
Once the incoming queue is congested everybody waits.
Another way to deal with a slow destination is to
drain in quickly to a second Postfix instance, where
the incoming queue may grow large, but you won't care
(you may want to zero in_flow_delay on the receiving
side). Then the input Postfix will never have a
large active queue and can handle high priority
traffic promptly.
--
Viktor.
