On Wed, Oct 22, 2008 at 02:42:09PM -0400, Ofer Inbar wrote:
> What I expected to see, however, is that when in_flow_delay were
> trigerred, each smtpd process would not be taking in multiple messages
> per second. Seeing that they were taking in multiple messages per
> second (per process ID) when I have in_flow_delay=10s is why I said
> "in_flow_delay is apparently not trigerring"
It takes in its share of the messages/sec that the queue manager can keep
up with, and then some more with each experiencing the in_flow_delay.
The (sustained) rate of incoming queue growth is bounded by the smtpd
process limit / in_flow_delay. Bursts are possible, because the in_flow
tokens are reset to the default_process_limit whenever the queue manager
completes an "incoming" queue scan.
> > As mentioned in the capitalized text above, the input flow rate
> > will be allowed to exceed the output flow rate.
>
> Right. I didn't say that I expected in_flow_delay to prevent input
> rate from exceeding output rate. However, I expected it to *slow* the
> input rate when the input rate exceeds the output rate. When I say
> "doesn't seem to have any effect" I don't mean "doesn't seem to be
> keeping the input rate below the output rate", rather, I mean "doesn't
> seem to have ANY EFFECT" (emphasis added).
No, the input rate will not slow, rather it won't rise as fast as it
would without the control.
> In other words, I expected the conditions I described to be conditions
> under which in_flow_delay would be triggered, and thus I expected to
> see its effect (fewer messages per second per smtpd process), and yet
> I did not see any such effect, which led me to wonder when and how it
> would be triggerred, and what effect I should actually be looking for.
No, not fewer total, fewer than you would get without the control with
input allowed to totally starve the queue manager.
> I still want to confirm what the observed effect should be:
> When in_flow_delay is being enforced, does that mean I should see in
> the log file that each smtpd process is accepting new messages no
> faster than once every in_flow_delay seconds?
No, rather on average this + the rate at which messages enter the active
queue / smtpd process count.
--
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:[EMAIL PROTECTED]>
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.
