On Sat, 7 Oct 2006, Noel J. Bergman wrote:
Brian,
The caching algorithm in dnsjava should be fairly simple. Calling
setMaxEntries() sets the number of DNS nodes (names) in the cache;
all information about individual records with the same name is stored
in one node. The data structure is a LinkedHashMap with LRU semantics,
to ensure that only a certain number of elements are retained.
So does that mean that Stefano's concern:
Unfortunately I think that in current DNSServer implementation we
can only tune the "IN" cache and not SOA, PTR and other caches. So
they will be 50000 anyway.
is unfounded, because there is only one cache, which we prepare as:
cache = new Cache (DClass.IN);
cache.setMaxEntries(maxCacheSize);
Lookup.setDefaultCache(cache, DClass.IN);
Yes, there's one large (per-class) cache, and it includes data of all
types.
I can't think of any reason why the number of elements wouldn't be
properly bounded
Neither can I.
if the problem is that maxCacheSize nodes takes a lot of memory,
that's not really fixable without changing the way nodes
are stored.
Approximate memory as to how much each node consume?
It depends on the data, mostly. A records will take less space than PTR,
because the A data is stored as an int, and the PTR data is stored as a
Name. There's going to be some per-node overhead: the cost of the
LinkedHashMap entry, the amortized cost of the Map itself, the node's
name/type/class/ttl, etc. There are a number of optimizations to make the
common cases use less memory, but I don't know if they apply to your
cache.
It's easy enough to get a rough measurement of how much 50000 nodes takes
with a small test program, but it really depends on the format of the
contents for it to be at all useful.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
