On 02/10/2011 07:13 PM, Ralf Hildebrandt wrote:
Goal:
=====
Make mails go to a target server within 60s.
Target server is defined as either:
* the MX host of the destination domain
* my smtp_fallback_relay which keeps trying delivery
It's really fast and can take a lot of load...
... but can it absolutely, guaranteed, accept ALL mail immediately, and
process it within your left-over timeframe ?
That seems like a measurable quantity, but you could start with one-half
of the 60 seconds for simplicity, so both possible targets have the same
30-second timeframe to attempt delivery.
Which timeouts should I lower? I think reaching a fixed threshold
won't be easy (since many of the timeouts below could add up under
unfortunate circumstance). Yet, the target systems are in a friendly
environment (no spamd-like characteristics). Just normal (but maybe
really busy and easily overwhelmed) MTAs!
I was primarly thinking of lowering:
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s
smtp_data_init_timeout = 120s
smtp_data_xfer_timeout = 180s
smtp_helo_timeout = 300s
smtp_mail_timeout = 300s
smtp_quit_timeout = 300s
smtp_rcpt_timeout = 300s
smtp_rset_timeout = 20s
smtp_starttls_timeout = 300s
smtp_xforward_timeout = 300s
If these machines are all on a high-speed LAN, why not lower all
timeouts to the practical minimum?
You'd need to test this with load anyway, so put a test load on the
solution and start testing at 1 second timeouts.
Increment selectively for each failure you find until failures disappear.
and I'm not sure how
smtp_connection_reuse_time_limit = 300s
could be lowered in such a way that busy destination MXes are not
keeping a lot of mail in the active queue...
Since it is a per-destination setting at best, it depends on how many
concurrent destinations you expect to handle.
In fact, if this setting is applicable to fallback_relay, you would want
to keep that one open indefinitely.
You could either lower this value, or increase the limit on smtp
processes, or both.
--
J.
