Comments (10)
I see that right now you're using rememberForever all over the place...
that could quickly lead to a problem where the cache fills up.. I'm not sure if there's some kind of automatic garbage collection that would happen here.. but I think it would be preferable to allow us to configure how long things should be cached for
from laravel-model-caching.
Hi @vesper8,
Due to the nature of Eloquent relationships the entire "stack" of a given model must be flushed anytime a model record is updated. You are right, if you have a updates-versus-reads ratio of 1:1 then caching makes no sense. However, you are likely to have more reads than writes, so it will increase performance overall.
By implementing caching you are not actually taking a performance hit, but rather eliminating one - the processing it takes to implement the cache is negligible from what I can tell. So think of it like this: if users are updating comments multiple times per minute during peak hours, you might not be gaining much, however, you will benefit during off-peak hours.
I do see your point. Unfortunately I don't see an elegant solution for it in this package.
I could look into optimizing the cache for relationships when child-elements are added, say comments are added to a given post, then it would only flush the cache for that post, like you say. I will have to ponder on this and see how it would be best implemented.
Thank you for walking me through your scenario! :) You definitely have good ideas, implementing them may be more difficult, though . :)
from laravel-model-caching.
@mikebronner Thank you for explaining. I guess you're right it's not really forever at all because of the way it aggressively invalidates currently.
Would there be a way to make this less aggressive on the invalidation part? Right now for example I have thousands of users and they have many model relationships. One example is users can post comments in threads.
Right now threads and comments are cached and that's fine. If someone adds a new thread then yes it makes sense to invalidate caches that contains threads because otherwise the new thread won't show up
However if a user adds a new comment to a single thread.. then it is kind of a huge performance hit if suddenly this invalidates ALL comments cache when ideally it should only invalidate the comments for the specific thread where the comment was added.
In an application where you have lots of users constantly adding comments.. like multiple times per minute.. then this would mean that the cache for all comments would be constantly flushed and basically it is as if it wasn't cached at all.. possibly making the performance even worse because of the constant cache-filling and cache-flushing
I could come up with many other examples where a full tag flush would be basically overkill and counter-productive.. could this be improved by adding model-ids to the tags ?
What are your thoughts on this?
from laravel-model-caching.
@bitclaw
I believe it comes down to configuring redis or memcached correctly. You want to set up a max-memory usage, and it should then manage itself. Cache memory filling up is not a bad thing, it's just a problem if it doesn't release old data to make room for new data.
The key here is to configure redis appropriately, as that part is out of the hands of this caching package.
from laravel-model-caching.
@vesper8 Thats a good point. Memcached automatically flushes stale items, and I believe Redis dumps items if it runs out of memory.
But it is not really forever, since you will invariably add new records to all of your models at some point, which will flush the cache. And if you don't ever add, update, or remove a specific model in your database, then the forever cache is what you want. (Any time you add, update, or remove a record of a given model, that model's cache is invalidated.)
If you use a cache without tag support, then the entire cache (not just the items pertaining to models) will be flushed. There is no way around that. The best solution then is to create a cache connection specific to model-caching (which you can configure), then only that cache is flushed. You may wish to create two Redis or Memcached cache instance: one for your app in general, and another for the model cache. That way you don't have to worry about your app cache being flushed unexpectedly. :) I should add this to the documentation.
from laravel-model-caching.
I can certainly see value in providing a feature to allow individual models to override how long they will be cached for as per the comment by @vesper8 a few days back. For example, I might not mind a specific model being stale for 5 minutes and I perform some direct database updates to that model's table. It would be great to still be able to benefit from caching in this circumstance without having to flush the entire cache for that model.
from laravel-model-caching.
Yes, this is definitely an interesting use-case. I will keep thinking on this. For the short term, I don't see this being implemented just yet, until the package is refined some more.
from laravel-model-caching.
I'm going to close this issue, as the thread diverged from the original request, but will open a new issue to keep the idea alive.
from laravel-model-caching.
I see that right now you're using rememberForever all over the place...
that could quickly lead to a problem where the cache fills up.. I'm not sure if there's some kind of automatic garbage collection that would happen here.. but I think it would be preferable to allow us to configure how long things should be cached for
This actually happened to us on a high traffic web site. We had switched to redis for caching and it consumed our 16GB of RAM on our redis instance in a couple of hours. Then I had to switch to file based caching and setup a scheduled task to clear the cache every three hours or so.
from laravel-model-caching.
@bitclaw
I believe it comes down to configuring redis or memcached correctly. You want to set up a max-memory usage, and it should then manage itself. Cache memory filling up is not a bad thing, it's just a problem if it doesn't release old data to make room for new data.The key here is to configure redis appropriately, as that part is out of the hands of this caching package.
Thank you for getting back to me. That makes a lot of sense, I believe for redis you can set the max memory usage https://redis.io/topics/lru-cache.
from laravel-model-caching.
Related Issues (20)
- Saving not working with eloquent strict mode HOT 2
- What is cacheCooldownSecounds definition? HOT 1
- Add support for Laravel 10 HOT 2
- Object of class Illuminate\\Database\\Query\\Expression could not be converted to string HOT 6
- Since 0.12.4 I get error "GeneaLabs\LaravelModelCaching\CacheKey::processEnum(): Argument #1 ($value) must be of type BackedEnum|UnitEnum|string, null given, called in ...\vendor\genealabs\laravel-model-caching\src\CacheKey.php on line 409" HOT 23
- Cannot access "parent" when current class scope has no parent HOT 1
- Laravel v10.3.0 breaks LaravelModelCaching HOT 2
- checkCooldownAndFlushAfterPersisting(): Argument #2 ($relationship) must be of type string, array given, called in /var/www/html/vendor/genealabs/laravel-model-caching/src/Traits/ModelCaching.php on line 83 HOT 8
- Is table join supported? HOT 7
- The attribute [column3] either does not exist or was not retrieved for model HOT 1
- Stale cached value returned where(...)->first() HOT 4
- Fix for GeneaLabs\LaravelModelCaching\CacheKey::processEnum(): Argument #1 ($value) must be of type BackedEnum|UnitEnum|string, null given
- processEnum(): Argument #1 ($value) must be of type BackedEnum|UnitEnum|Illuminate\Database\Query\Expression|string, null given HOT 2
- Conflict with Spatie Schemaless
- Laravel 11 upgrade blocked by laravel-pivot-events dependency HOT 1
- Missing import in CachedBuilder?
- Fix failing tests HOT 1
- Uuid fromBytes throwing a error HOT 1
- Observer for Pivot Model not firing HOT 3
- Bug: CacheKey::getValuesFromBindings(): Return value must be of type string, null returned | when where value is null HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from laravel-model-caching.