Forum Discussion

liaodm's avatar
liaodm
Contributor
11 years ago

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 ...
  • DavidE's avatar
    DavidE
    11 years ago

    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

    1. The result of processing 250+ messages
    2. The result of processing every topic from a board in an O(n^2) algorithm
    3. 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

    1. Storing a single users profile info and avatar
    2. 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,

     

DavidE's avatar
DavidE
Lithium Alumni (Retired)
11 years ago

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

  1. The result of processing 250+ messages
  2. The result of processing every topic from a board in an O(n^2) algorithm
  3. 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

  1. Storing a single users profile info and avatar
  2. 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,