-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[req]: Use database caching instead of RAM #15007
Comments
While I agree this would be useful, even just completely changing over to database caching (supporting both it and RAM caching seems unnecessarily complicated), this would be dependent on a contributor or our sole active C# maintainer having time to do so. Don't expect anything quickly. |
Easiest way would be using an ORM https://learn.microsoft.com/en-us/ef/core The Cache class doesn't seem too complicated to migrate. Unfortunately I have 0 experience with C#. |
I stumbled upon this as I was running the docker container and asking myself why I couldn't store my cache elsewhere, even just in a SQLite database on an AWS bucket or something. I am a .NET dev. and, unless I'm missing something, I think it would be relatively straightforward to build multiple implementations of the cache class that plug into a multitude of backend solutions (in-memory, Redis, SQL/NoSQL databases, etc.) Right now it's just using a dictionary with a lock, I think, which will be slow. I will try to have a look at this in the next few months -- I am also busy unfortunately! |
my 2 cents: another simpler solution could be to limit the cache storage to a defined amount of RAM. Old cache entries would be dropped from memory. Maybe something like a TTL for every cache entry? the TTL could be configured by env. |
We already have a cache TTL setting. |
Is there already a request for your feature?
Is your feature request related to a problem? Please describe.
There's this streaming app called Stremio, and I recently found an add-on called stremio-jackett. It basically queries a Jackett server and returns the results to the app. It takes quite a while to do the initial query, but after it's cached it's pretty quick (normal behaviour)
However here comes the problem: There are many self-host options for Jackett servers. And some of them have limited RAM (Mine used to have 512MB, now it has only 1GB). And storage is definitely cheaper than RAM.
(I run lots of thing in this same EC2 instance)
Describe the solution you'd like
So my idea is to have a toggle to cache using something like MongoDB instead of RAM. It'd still be quicker than re-querying all trackers and wouldn't end up consuming lots of RAM eventually. This could also lead to a perpetual cache, instead of a limited-time cache in RAM, which I'd think is even better.
Describe alternatives you've considered
No response
The text was updated successfully, but these errors were encountered: