On Wed, Apr 21, 2004 at 08:27:58PM -0700, Jeff Chan wrote:
On Wednesday, April 21, 2004, 7:55:33 PM, Simon Byrnand wrote:
At 14:39 22/04/2004, Eric Kolve wrote:
I can add something that will cache on a per test basis the results from the queries so the above scenario should be knocked down to just 3 queries instead of 120. I have been a little hesitant to cache misses since I could see where a miss could become a hit later on, but since I would only be caching per test this shouldn't be an issue.
You mean 6 queries ? Assuming you still test both 2nd level and 3rd level possibilities seperately, as now.
It sounds like Eric is changing SpamCopURI to test on the number of levels depending on ccTLD membership, which is probably fine, therefore it would do 3 queries.
And as far as caching goes, it shouldn't be a problem, because you just want to avoid doing a whole string of identical dns lookups - only cache identical lookups, and the caching should only last for one run of SA processing one message...(We assume that no new blacklist records appear in the middle of processing a specific message, or that if they do we don't care ;-)
Yes, it's not clear if "per test" means per message, but it would seem so. That too should be fine. I don't think we should worry too much about the boundary condition of the SURBL changing in the middle of message processing, which seems like it would be uncommon. Per-message caching is already a big help.
'per test' literally means per test. So if you run three eval:check_spamcop_uri_rbl tests, then you will have at most three queries for the same domain.
I would cache per message, but there isn't a good place to cache this data. I have access to PerMsgStatus, but its not a good idea to start shoving stuff into that hash as other code depends on its structure.
--eric
Jeff C.
Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss