With Postfix 2.5 I introdoced stress-dependent behavior in the SMTP
server, but this was left turned off by default.
I'm thinking of turning on some stress-dependent behavior by default
in Postfix 2.6, to make Postfix look better in stupid benchmarks
(just like in_flow_delay and smtpd_client_connection_count_limit).
While I am reluctant to make the default SMTP server timeouts
drastically shorter, I am inclined to ship Postfix 2.6 with settings
that will be relatively safe under conditions of overload.
Something that will drastically cut the time per session:
smtpd_timeout = ${stress?10s}${stress:300s}
smtpd_hard_error_limit = ${stress?2}${stress:20}
This would affect clients that cannot send SMTP commands within
10s from each other (i.e. round-trip time >5s) or cannot send blocks
of message content within 10s from each other (i.e. an effective
bit rate of < 1500 bits/second).
Keep in mind that we're doing this only when the server is saturated.
By not receiving very slow mail, we create more opportunities to
receive other mail that arrives in less time. This assumes that
the condition is temporary, and that some bit rates will stay above
1500 bps.
Another issue is smtpd_timeout granularity. Currently it is the
same for all SMTP commands, but some suggested it makes sense to
distinguish between some of the SMTP stages.
Suppose we have two settings, one for the DATA stage where we have
valid recipients, and one for the non-DATA stages.
Then, the default settings would look like this:
smtpd_timeout = ${stress?10s}${stress:300s}
smtpd_data_timeout = $smtpd_timeout
$smtpd_non_data_timeout = $smtpd_timeout
smtpd_hard_error_limit = ${stress?1}${stress:20}
I would not make different stress dependencies for _data_timeout
and _non_data_timeout, but people would be welcome to use the extra
rope and shoot themselves into the foot.
Wietse
