MXToolbox - Exchange Transaction Times RSS Back to forum
@Mandeep Khalsa:
Without more information, it is hard to tell if this indicates a problem with ORF configuration or not. Here are a few things to consider.
ORF filters emails real-time, during the SMTP transmission. Emails are held up while ORF performs its tests, which increases the transaction time. Based on what you described, it is indeed ORF testing that takes about half a minute.
32 seconds _average_ for testing sounds a little too much. This is almost always due to time consuming operations, which are Tarpit, DNS lookups and database operations in ORF.
* Tarpit Delay: If Tarpit Delay is enabled, ORF will hold blacklisted up emails for the configured time period. This is the very point of Tarpit Delay. Check if this test is enabled and if it is, turn it off and see how that affects the transaction time.
* DNS: Each DNS lookup takes time, typically less than a second. DNSBLs, SURBLs, Reverse DNS and the SPF Test all take time to complete and this could add up. Also, the number of DNS servers specified for ORF and your DNS timeout affects the maximum total time. Let's say ORF performs a Reverse DNS lookup for a domain not available + you have 4 DNS servers configured + 12 seconds DNS timeout. Because ORF will attempt all for DNS servers on timeout, this can potentially take 4*12 seconds. General recommendations:
1) Have max. 2 DNS servers configured in ORF
2) Have no more than 12 seconds timeout (for servers under high load, this can be as low as 2-5 seconds).
3) Consider the number of enabled DNS-based tests vs. transaction time.
4) For troubleshooting, check your ORF logs for timeouts. A few timeout errors are normal, but when your log overflowing with them, this could indicate a problem with the DNS server or the queried DNS service (like a DNSBL).
* Database operations also take time. The Private Local Databases of ORF may be employed for approx. 50,000 emails/day load or less. Above that, database operations might time out, also causing excessive transaction times.
On the other hand, 32 seconds should not cause any email loss you described, unless your server is under extreme load (like a couple of hundred thousands emails a day). Such email loss may occur if the SMTP transactions time out (32 seconds should be within timeout in the vast majority of cases), or if no connection could be made to your server. If either of the above occurs repeatedly, the sending server might give up delivery after a few attempts and hence the loss. IIS SMTP/Exchange is massively parallel, able to handle 10+ connections at once, but if the transaction count is in the hundred thousands, long transaction times might eventually consume all available connections, resulting in dropped connections. Careful test selection, or better email distribution among multiple servers is required for those large-volume setups.
Peter,
I checked the settings you mentioned above and there are only 2 DNS servers listed, both internal. I also have tarpit delay enabled with a delay of 60 seconds (I don't remember changing it).
I did turn off tarpit delay and transaction times went down below 1 second.
Thanks for your help on this.
Mandeep
Hello All,
I have been using ORF for several years and recently we moved our email server from a physical host to virtual (ESX 4.1) since then we have been having issues with random emails being rejected etc.
I looked into it and as per www.mxtoolbox.com we are getting transaction times in access of 32 seconds. I turned off things on the firewall and other areas but it all remained the same, until I turned off ORF and ran the test again. My transaction times dropped from 32+ seconds to mere .45 or less.
We are running all the tests except DNS Whitelist, DHA and Honeypot. Can anybody explain why the performance is being degraded in excess of 30 seconds for each transaction?
Thanks