Jeff Koch <[EMAIL PROTECTED]> writes: > We have had delay problems with SBL, RCFI, DYNABLOCK, NJABL - even SPAMCOP > gets overloaded on occasion. Once we start getting network test delays the > problems cascade very quickly and load averages escalate to the stratosphere.
Sure, occasionally that does happen. SA now times out dead blacklists very quickly on each query. The major delays are from the MX test (before pre-3.0.0-rc1), Pyzor, DCC, and Razor2 -- as I told you already. If you're using those remotely (no local server/mirror), then you're wasting your time worrying about DNSBL performance. > I question your statement that these DNSRBL can handle the load. Our > mailservers are handling over 10K messages per hour Sites with high volume generally use local copies of blacklists. That is considered a best practice. It doesn't require any code changes on our part, though. 10K messages per hour is not very big, but you might want to think about it. > - but to be conservative assume there are a million SA boxes checking > 1.0K messages per hour. Is it reasonable to assume that each DNSRBL > can handle a billion queries an hour? A lot of people don't use network tests, plus a lot of sites download local copies of some, most, or all of the DNSBLs they are using. I believe we generate about 520 million queries per hour. > I also believe that SA should provide a mechanism for logging network test > response times. We need to be able to quickly turn off tests that create > delays. We might be willing to consider logging any slow/slower responses in spamd. We'd want to see what the performance impact would be. I tried tracking per-DNSBL performance between spamd processes and it was *way* too expensive and slowed things down on average. The current timeout mechanism is very fast and efficient. Read the rbl_timeout documentation. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
