Jan-Pieter Cornet <[EMAIL PROTECTED]> writes: > OK, done, bug #3881.
Thanks. >> My secondary concern is that you'll never almost get responses from >> other blacklists and this might result in a lower hit rate (since a >> negative response is still a response). That should probably be >> addressed via early exit on high score, though. > Sorry, I completely lost you. Could you rephrase? The timeout scales dynamically based on how many blacklists have already replied (see the rbl_timeout documentation). If you have enough of them locally mirrored, then you'll almost never see results from external blacklists unless the non-network tests required more time. > The only disadvantage I see is this scenario: code is still waiting > for a few DNSBL results. $timeout is drawing near. One of the results > come in, and because of the select(), the code immediately processes > it, and re-enters the loop, but now the $timeout is even less due to > the dynamic timeout, so the dnsbl harvest loop is terminated. That's what I meant. :-) > I find this scenario a bit unlikely, but it is a possibility. But if > this really does concern anyway, then why is the dynamic timeout there > in the first place? :) Because not having a dynamic timeout is way too slow. The current code always waits one more second which is enough time for the slow, but not *really* slow blacklists to respond. Maybe the performance tradeoff just isn't worth it. >> Can you look at average CPU user+system time? > I'll have to instrument the code to do that. The times I showed > earlier aren't "spamassassin" runs, it's calls to the library, from > MIMEdefang... but I'll add some calls to getrusage before and after. You can use Devel::DProf or Devel::Profiler to do that too. Thanks. Daniel -- Daniel Quinlan ApacheCon! 13-17 November (3 SpamAssassin http://www.pathname.com/~quinlan/ http://www.apachecon.com/ sessions & more)
