[websissy]

Okay. I get it. I think you're saying there's no need to add a log scan when you already have the cache scan working and can easily increase the cache time. Makes sense. Also makes sense to only keep not found items in the cache for 30 minutes or so but keep the found (blacklisted) items in the cache longer. Again, the goal is to reduce the central server load. Why waste its time and energy checking on a bot it rejected an hour or two ago trying to join the same site?

Gotcha. Over time, perhaps you should consider dynamically adjusting the size / duration of the local cache size based on time or the volume of requests processed by that site. That way smaller sites with lower volumes might be able to cache 24 or 48 hours of requests and drastically cut their reliance on the central server while larger / busier sites would not be penailzed because they receive more requests but might rely more heavily on the central server instead. For instance, you might cap the size of local cache at say 300 / 600 entries or 24 / 48 hours whichever came first. It's a thought.

600,000 calls per day is 25,000 calls per hour or 417 calls per minute. With that volume of requests, it's no wonder you're having DNS server outages and server/DB overload problems. I'll bet you cut that load in half by increasing the local server cache time to 12, 24 or 48 hours.

I'll bet Floris and other busy site operators like him would approve of this approach and small site guys (like me) will get better performance and less service outages too.

Good solution! Hope my thinking about this helped.