8000 Feature Request: Enhance "Cache Maximum Entries" Parameter · Issue #1774 · TechnitiumSoftware/DnsServer · GitHub
[go: up one dir, main page]

Skip to content

Feature Request: Enhance "Cache Maximum Entries" Parameter #1774

@sproggit

Description

@sproggit

### Summary ###
A proposal to make the setting of the Settings >> Cache >> Cache Maximum Entries parameter a bit more user friendly.

### Existing Approach ###
In the parameter options for the local server cache, the software has the ability to express a maximum cache size based on the number of entries it will contain. However, there is no information provided in the setting of this parameter or the overall documentation to show how to calculate the per-item memory consumption [which is going to vary considerably based on the length of the name for which address resolution is requested].

**### Suggested Alternatives ### **
There are a couple of ways that it should be possible to provide helpful information regarding this [and perhaps other] settings.

First, in terms of making this parameter a bit more user-friendly, it might be possible to express the cache size in terms of memory consumed [Kb, Mb, or perhaps even Gb]. Of course, this is going to require a reliable calculation mechanism to ensure that the memory footprint of the cache is known at all times... but that should be possible because the cache is a single structure, likely maintained by a Singleton Object. That Object would have at least two methods in it - one to add a new entry to the cache and one to remove the entry.

It seems reasonable that for performance reasons the cache is using something like a Red-Black Tree or an AVL Tree (possibly a Prefix Trie)... so if this were presented via a singleton, then each time a name-address pair was added to the cache, the instantiated object could determine the length and add that to a running "tree size" attribute. Likewise, when an entry is purged from the tree - if it ages off the cache - then the value can be removed from the running "tree size".

But this might be a more realistic way of allowing a user to set a cache size, especially when the per-object size is potentially going to be so incredibly variable.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0