Cache tuning - key-specific TTL settings?
I've started experimenting with appcache to store a sequence of REST query results for use in multiple custom components (see related Knowledge Base article).
I understand that only Professional Services has control over cache settings (time to live after write and after access), but how detailed does that control get? Can I request a specific appcache key to have its own TTL settings, or are the settings only tuned at the application or user level?
Also, what methods are available to programmatically clear a cache key? Would I just call appcache.put("myKey", []) to empty a cached sequence, or is there some other approach I should use? If I have a cached sequence of Kudoed messages for example, then I may want to clear that key when a new Kudo comes in, so that end users don't see stale content.
Thanks.
Hello liaodm,
I will try to answer all you questions in order, but if I miss anything or you want more information, please feel free to reply with more questions.
tl;dr; Configurable in ms only at the user/app level. Caches serve stale data and invalidating the cache on events is really hard.
____
Professional Services is able to configure the time to live after write and after read to millisecond precision. The appcache and usercache can have two different timeout values, but every entry will have the same timeout in the respective caches. So you can set usercache timeout to 1 hour and app cache to 24 hours, but you cannot set an individual timeout for each entry. However, we have talked about implementing this since it would be so useful. Unfortunately there is a lot of work on the backend to make it possible. Feel free to create a product suggestion for this functionality http://community.lithium.com/t5/Product-ideas/idb-p/Lithium_Ideas.
Right now there is no way to invalidate an entire cache or cache key. The method you suggested is the best approach for now. You mentioned invalidating the cache based on entity/community events. This would be fairly complicated to do but might overly complicate the API. We would need to figure out a way to specify which event and entities should be watched to invalidate the cache key.
When using a cache, you are trading real-time information for performance. Unfortunately you cannot have both. In other words, using the cache presents a risk of serving stale data. However, often this is ok for most usecases. Because of this trade off, the caching should only be used to store results from expensive operations. A few examples are
- The result of processing 250+ messages
- The result of processing every topic from a board in an O(n^2) algorithm
- The result of processing All of a users friends, friends, friends (3 levels of graph traveral).
A few examples for when NOT to use the cache
- Storing a single users profile info and avatar
- Storing the 10 most recent messages from a board
If you are using 5 or more rest api calls to render a component, you should considering using the cache, unless the information needs to be real time.
I hope that answered everything (with a few useful tangents). Again, please feel free to respond with any questions,
