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. > 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). 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. This would slow down the message rate between Postfix and filter without immediate blocking. Thanks, Martijn
