On Fri, Jan 30, 2009 at 01:45:29PM -0600, Noel Jones wrote:
> Victor Duchovni wrote:
>> On Fri, Jan 30, 2009 at 08:14:22PM +0100, Martijn Brinkers wrote:
>>> If I'm not mistaken the described approach (with
>>> fragile_destination_concurrency*) works when you have small bursts of
>>> errors. In my case it can take some time before connections are allowed
>>> (email is again allowed when the filter queue size drops below a level).
>>>
>>> Currently my filter return 450 when the queue is below a certain level.
>>> Would it be better if I add connection 'throttling' instead of
>>> immediately returning 450? So:
>> Eliminate all queues from the filter, it should be a proxy. Let Postfix
>> do all the queueing, it is much better at this than the filter.
>
> I didn't consider that the filter might not be a proxy.
>
> If that's the case, the design of the filter is broken and it will be
> difficult to "fix" in postfix.
If the filter wants to queue, it should accept mail essentially regardless
of its queue size. If latency is too high, add more filter boxes. In
practice the filter's queue should be always empty, with occasional
small spikes for bursts of large messages that gobble-up CPU. The
spikes should die down quickly. If this is not the case, add more
horse-power.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majord...@postfix.org?body=unsubscribe%20postfix-users>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
