Martijn Brinkers wrote:
On Fri, 2009-01-30 at 11:43 -0600, Noel Jones wrote:
Seems to me the first action should be to reduce the number of
smtp connections to the content_filter to a number it's able
to consistently handle.
There is a big difference in filtering speed between messages. The
filter is an encryption filter and encryption speed depends largely on
the message size. The connection between Postfix and filter need to be
fast enough to handle small messages.
But there probably isn't a big difference in the number of
simultaneous messages the filter can handle, independent of
message size/content.
I still think this should be the first action.
If that's ineffective for some reason, then implement the
suggestions outlined in
http://www.postfix.org/QSHAPE_README.html#backlog
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).
The example tolerates up to 2000 consecutive errors. Remember
it's an example and can be seasoned to taste.
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:
If the filter queue size is larger than 500 messages (lower level) wait
some time X in the RCPT handler of the filter and then continue
normally. If size is larger than 1000 (upper level) return 450.
Seems to me something is broken if the filter processing speed
is affected by the size if the postfix queue.
--
Noel Jones
