on the local machine, but the advantage is a global cache shared
across many machines - each benefiting from the previous scanning
results of the others.
Given how frequently body caches hits are, I would imagine that
for those of us with dozens of machines in a load-balanced setup,
we could see a pretty good hit rate.
We haven't had time to actually try it out yet, though. Has anyone?
Or does anyone have any long term cache-hit statistics? We've not
bothered to keep any record of that in the past.
Ed
On Jun 22, 2005, at 6:00 AM, Mark Martinec wrote:
<x-tad-smaller>Ed,</x-tad-smaller>
<x-tad-smaller>> We're playing around with memcached (</x-tad-smaller><x-tad-smaller>http://www.danga.com/memcached/</x-tad-smaller><x-tad-smaller>)</x-tad-smaller>
<x-tad-smaller>> as a distributed cache for some postfix stuff, and it strikes me that</x-tad-smaller>
<x-tad-smaller>> this could be an interesting fit for the amavisd-new cache of body</x-tad-smaller>
<x-tad-smaller>> message digests - particularly for those of us with numerous servers in</x-tad-smaller>
<x-tad-smaller>> clusters.</x-tad-smaller>
<x-tad-smaller>Here is my quick reply on the same subject from May 2005 to Yusuf Goolamabbas:</x-tad-smaller>
<x-tad-smaller>Subject: Would Danga's memcached be an appropiate tool for global cache</x-tad-smaller>
<x-tad-smaller>> Mark, I was wondering what you thought of Danga's memcached</x-tad-smaller>
<x-tad-smaller>> </x-tad-smaller><x-tad-smaller>http://www.danga.com/memcached/</x-tad-smaller>
<x-tad-smaller>> as a possible tool to replace BDB as a global cache. This would also</x-tad-smaller>
<x-tad-smaller>> allow multiple amavisd instances in a cluster to share a centralized</x-tad-smaller>
<x-tad-smaller>> cache. I'm not sure if you require a persistent database for some</x-tad-smaller>
<x-tad-smaller>> purpose within amavisd</x-tad-smaller>
<x-tad-smaller>I guess it is a possible tool for a global cache, but not for</x-tad-smaller>
<x-tad-smaller>the database of snmp-like counters, which requires atomicity</x-tad-smaller>
<x-tad-smaller>of counter updates, and probably not useful for nanny database.</x-tad-smaller>
<x-tad-smaller>The speed here is a non-issue, the bdb does its job quite fast.</x-tad-smaller>
<x-tad-smaller>On the other hand, keeping a global cache in memory is probably</x-tad-smaller>
<x-tad-smaller>a waste of resources, it doesn't help much with speed.</x-tad-smaller>
<x-tad-smaller> Mark</x-tad-smaller>
