AdGuardHome
AdGuardHome copied to clipboard
AdguardTeam
Request to add support for redis backend cache
Prerequisites
-
[ ] I have checked the Wiki and Discussions and found no answer
-
[ ] I have searched other issues and found no duplicates
-
[ ] I want to request a feature or enhancement and not ask a question
The problem
https://github.com/AdguardTeam/dnsproxy/issues/368
Proposed solution
Request to add support for redis backend cache
Alternatives considered and additional information
No response
A cache is just that though, a cache. What does it matter if AdGuardHome has to go and lookup things again when clients request them? Clients that almost certainly have their own cache.
If this really IS a problem, why not setup a recursive cache on the same network (Unbound is fantastic) and use that as AdGuardHome's DNS upstream? That way even if you do restart AdGuard, the upstream DNS server (which'll be on the same LAN so no latency) will respond with its cached entry. The only thing you potentially lose if if you're extending the TTL's artifically on AdGuardHome, your upstream cache won't do that. Though that said, there's other recursive DNS servers that can modify the TTL as well - again Unbound is great and can do this.
IMHO I don't think adding a redis cache is the right thing to do, DNS cache is just that, cache. What problem does this really solve apart from some slightly longer lookups for your clients, who almost certainly have their own cache anyway?
A cache is just that though, a cache. What does it matter if AdGuardHome has to go and lookup things again when clients request them? Clients that almost certainly have their own cache.
If this really IS a problem, why not setup a recursive cache on the same network (Unbound is fantastic) and use that as AdGuardHome's DNS upstream? That way even if you do restart AdGuard, the upstream DNS server (which'll be on the same LAN so no latency) will respond with its cached entry. The only thing you potentially lose if if you're extending the TTL's artifically on AdGuardHome, your upstream cache won't do that. Though that said, there's other recursive DNS servers that can modify the TTL as well - again Unbound is great and can do this.
IMHO I don't think adding a redis cache is the right thing to do, DNS cache is just that, cache. What problem does this really solve apart from some slightly longer lookups for your clients, who almost certainly have their own cache anyway?
There's no need. We want features that people like you deny. What's the point
Huh? I'm not denying you anything - I'm just a user like you. This is my ~4th comment ever on the AdGuardHome project.
I, personally speaking, can't see what the point of a REDIS cache for DNS cache entries would be. Why bloat the codebase to save/restore cache entries into REDIS, for no real performance gain?
But I've been wrong many, many times before. So many times. So I'm really curious what the use case/performance saving is going to be? I can't figure out what it might be. And even though your original request just says "Add redis cache support" and references another comment on the DNSProxy that pretty much says the same thing (i.e. neither explain what the performance/reason/gain is for doing so), you've taken the time to submit the issue so there must be a good reason for it, so I'm keen to hear it. Highly likely it is a great idea and I'm just ignorant to it, and will look like a fool shortly.
Either way - I'm denying you nothing. You have just as much weight and capability to state your case to the developers as I do - we're peers here.
Alas, see new features. It feels like no one's expecting it. It's all stomping. This feature was proposed a few years ago, but was not developed. Any development is a step on.
What is the point of a feature if it has no use?
Why not add disco party mode to the UI?
What is the reason you feel a REDIS cache would be beneficial? It's not a hard question.
What is the point of a feature if it has no use?
Why not add disco party mode to the UI?
What is the reason you feel a REDIS cache would be beneficial? It's not a hard question.
According to what you mean, can I understand that unbound does not need to support redis? But in fact, unbound supports redis.
What is the point of a feature if it has no use?
Why not add disco party mode to the UI?
What is the reason you feel a REDIS cache would be beneficial? It's not a hard question.
I can also understand that any configuration of adguard home can be configured through the AdGuardHome.yaml file. The current AdGuardHome web ui is completely unnecessary. This also increases the size of the AdGuardHome file and does not improve any performance. So can I ask the official to delete the code of AdGuardHome web ui?
It feels like it's gone bad, and I'll step on any questions and new features.
Please keep the conversation on topic.
@Potterli20, AdGuard Home, as the name implies, is intended to be used on small networks as well as on PCs and laptops. It's reasonable to ask what problem is being solved, whether it's a common one, given the scope of the project, and discuss ways to solve it (why Redis as opposed to an on-disk solution or another KVDB?).
Please keep the conversation on topic.
@Potterli20, AdGuard Home, as the name implies, is intended to be used on small networks as well as on PCs and laptops. It's reasonable to ask what problem is being solved, whether it's a common one, given the scope of the project, and discuss ways to solve it (why Redis as opposed to an on-disk solution or another KVDB?).
Redis is a clustering solution as well as persistence. We need this kind of caching. You will adopt this as well. And I don't think you're going to take on this development, because your project is only for home and small networks. However, there are also people in small networks who use Redis requirements. Actually, I don't like disk local, even if I tune to the largest cache, the most requests, the local cache is only 1k in size (it's been a long time ago)
Unbound supports redis because Unbound is used by ISPs in places where 50k+ people will be hitting a single Unbound Server as their recursive nameserver. Restarting things at that scale it can be good to have a hot cache to load in as to decrease load.
That said, at the ISP I work for we have a number of Unbound Servers that server 30k customers and if we take one out of service, we don't use a redis cache. No one complains when we restart it because it takes 120ms to tell them Facebook.com's IP instead of 5ms. And we just wear the additional load and CPU it takes on inital startup, it settles quickly.
I understand and agree with the idea of having more than 1 AdGuardHome instance in a network, that way you can take one out of service without breaking the home network. But surely "Config File Sync" is what you want implemented here. In fact all the previous comments have been about a redis cache, to suggest you need it for clustering now seems... odd. What problem does redis solve there? It's a key store cache, not a file/config sync program.
And surely you can't want redis for hot-cache load, because is anyone really going to notice the extra latency if AdGuardHome has to go to an upstream DNS server to resolve something because it's not in a local cache? Especially when most clients will have things cached anyway.
Thus far, no one in this thread has been able to explain what or why redis would be a good idea except for some vague "AdGuardHome Clustering" statements.
I am NOT saying adding redis is a bad idea, or bloat, or anything. I am asking you to explain what technical problem you're solving, with at least a tiny bit of detail. Not vague "Oh clustering" comments. How would redis help AdGuardHome cluster? What would be the advantage of using redis vs some lightweight config sync protocol, which surely is what we'd want so both AdGuardHome's have the same configuration aside from their IP address.
So far not a single post has explained anything. All they've been is "Oh well if we don't need redis why do we need a GUI" and other such things, none addressing my question. I'm starting to think you don't actually know why you think AdGuardHome needs redis, you've just read "redis fast!" on Reddit somewhere.
Unbound supports redis because Unbound is used by ISPs in places where 50k+ people will be hitting a single Unbound Server as their recursive nameserver. Restarting things at that scale it can be good to have a hot cache to load in as to decrease load.
That said, at the ISP I work for we have a number of Unbound Servers that server 30k customers and if we take one out of service, we don't use a redis cache. No one complains when we restart it because it takes 120ms to tell them Facebook.com's IP instead of 5ms. And we just wear the additional load and CPU it takes on inital startup, it settles quickly.
I understand and agree with the idea of having more than 1 AdGuardHome instance in a network, that way you can take one out of service without breaking the home network. But surely "Config File Sync" is what you want implemented here. In fact all the previous comments have been about a redis cache, to suggest you need it for clustering now seems... odd. What problem does redis solve there? It's a key store cache, not a file/config sync program.
And surely you can't want redis for hot-cache load, because is anyone really going to notice the extra latency if AdGuardHome has to go to an upstream DNS server to resolve something because it's not in a local cache? Especially when most clients will have things cached anyway.
Thus far, no one in this thread has been able to explain what or why redis would be a good idea except for some vague "AdGuardHome Clustering" statements.
I am NOT saying adding redis is a bad idea, or bloat, or anything. I am asking you to explain what technical problem you're solving, with at least a tiny bit of detail. Not vague "Oh clustering" comments. How would redis help AdGuardHome cluster? What would be the advantage of using redis vs some lightweight config sync protocol, which surely is what we'd want so both AdGuardHome's have the same configuration aside from their IP address.
So far not a single post has explained anything. All they've been is "Oh well if we don't need redis why do we need a GUI" and other such things, none addressing my question. I'm starting to think you don't actually know why you think AdGuardHome needs redis, you've just read "redis fast!" on Reddit somewhere.
You've said so much, do you think I'm a novice? Who doesn't know this thing.
Again, no answer, just more, well I don't even know what you've tried to say this time. Which bit of my comment are you even replying to?
Let's try one more time before I give up: Why do you think redis would be a good fit for AdGuardHome? What technical problem does it solve?
I don't think you're a novice, but I do think you're a terrible communicator I'm sorry. You avoid, don't answer and just reply with nonsense.
Again, no answer, just more, well I don't even know what you've tried to say this time. Which bit of my comment are you even replying to?
Let's try one more time before I give up: Why do you think redis would be a good fit for AdGuardHome? What technical problem does it solve?
I don't think you're a novice, but I do think you're a terrible communicator I'm sorry. You avoid, don't answer and just reply with nonsense.
Please give up the horn. Because your reply is very unsatisfactory to me.
Again, no answer, just more, well I don't even know what you've tried to say this time. Which bit of my comment are you even replying to?
Let's try one more time before I give up: Why do you think redis would be a good fit for AdGuardHome? What technical problem does it solve?
I don't think you're a novice, but I do think you're a terrible communicator I'm sorry. You avoid, don't answer and just reply with nonsense.
Hello, no one answers you and I'll answer you now.
Redis would be a good fit for AdGuardHome because it can efficiently handle DNS query caching, which can improve performance by reducing the load on the main AdGuardHome server. Additionally, Redis is fast and can handle large volumes of data, which is crucial for a service like AdGuardHome that needs to process many DNS queries in real-time.
Again, no answer, just more, well I don't even know what you've tried to say this time. Which bit of my comment are you even replying to?
Let's try one more time before I give up: Why do you think redis would be a good fit for AdGuardHome? What technical problem does it solve?
I don't think you're a novice, but I do think you're a terrible communicator I'm sorry. You avoid, don't answer and just reply with nonsense.
Hello, I seeing the responses to this request, this is a community project and should be open. This redis proposal, like other things, must be reviewed and supported, because it will help some and it will not be necessary for others, but we should not fall into answers like the previous ones. Please support this proposal. Best regards.
Redis would be a good fit for AdGuardHome because it can efficiently handle DNS query caching, which can improve performance by reducing the load on the main AdGuardHome server. Additionally, Redis is fast and can handle large volumes of data, which is crucial for a service like AdGuardHome that needs to process many DNS queries in real-time.
How would redis improve performance over just caching the entires in memory which AdguardHome does already? That's what I don't understand. And again, like the other posters you've just sort of hand waved and gone "performance" without any technical details. Are you saying Redis is going to dramatically improve the caching mechanism AdGuardHome already has? If so, how?
For the added complexity of adding support for Redis, which means that AdGuardHome now has to call out to an external binary (Either via TCP or a Unix Socket) - what is the real world performance gain you expect Redis would bring - especially over it's existing caching implementation?
I'm sure adding Redis support wouldn't actually be a very difficult task for the developers, there almost certainly a robust Go Redis implementation. EDIT: Yup, there is.
But what is the actual performance increase/benfit that it'd bring? If AdGuardHome didnt have any caching already I could understand why including support for Redis might be useful. But it already does in memory caching. And as this project is designed/targetted at home users, it seems the additional code that would need to be written/added would increase the code that needed to be supported/debugged etc - increasing the change of bugs/errors creeping in. That's just the nature of a larger code base.
I'm not against this proposal. I love Redis, a number of other Open Source products I use make extensive use of it. I'm just challenging the "Performance will be better!" line that everyone keeps trotting out, because no one yet can articulate HOW permformance will be improved over the caching mechanism AdGuardHome already has. I understand that Redis would allow for a "fast reload" of the cache when AdGuardHome is restarted, but really does that matter for home use? Is anyone really going to notice their first facebook.com lookup only took 1ms instead of 50ms before AdGuardHome caches it in memory again?
Aside from the fact no one has yet made a good technical case for why Redis would be a good fit, the other reason I don't think it would be is because unless as an adminstrator you're very careful, a misconfigured Redis server (a world accessible one) can be exploited. There's many examples of this online. Again, given the Home User audience of AdGuardHome, I think adding a Redis cache into the mix might not be a great idea from a security point of view.
seeing the responses to this request, this is a community project and should be open. This redis proposal, like other things, must be reviewed and supported, because it will help some and it will not be necessary for others, but we should not fall into answers like the previous ones. Please support this proposal.
Surely it's fair of me to ask/justify what the actual technical benefit of a proposal is, isn't it? If someone proposed adding Oracle Database, or Google Analytics support to AdGuardHome, would you just blindly say "Yes, support this proposal" or would you ask what the actual benefit of the proposal was?
@ainar-g First of all, it is not necessarily necessary to support redis alone. It can also support other persistent database caches, such as keydb. @tjharman is very judgmental here. I don’t know why he hates redis so much. Is there a conflict between redis and him?
The issue about persistent caching in general is #3859. If anyone subscribed to this issue would like that in the future, please upvote that issue. (No “+1” comments, please.)
I'm not really sure if there is anything to be done here. Even if Redis support ever lands in AdGuard Home (likely later rather than sooner, considering the scope of the project), it will be set up as a kind of persistent cache, so any arguments regarding Redis are not really substantial until/if that feature is implemented.
Merging into #3859.