To handle high throughput, UGC utilizes the concept of Cache Keys. The UGC cache system with custom cache keys is very robust on sites that are heavy on both reads and writes. Implementing it requires much less work than implementing caching on your own. This will help for cases like UGC contests where a large number of people are submitting content for a short period of time which can cause the site to perform slowly due to cache churn.
Calls made with an Admin API Key (e.g. from Agility) are NEVER cached and saving records in Agility does NOT clear cache from the website.
Applying Custom Cache Keys
Using custom cache keys enables a scenario where a set of Records in a Content Definition are related to another Record or key and should be cached in a smaller group instead of being under the umbrella of the entire Content Definition.
The SearchRecords API method has a parameter for a custom cache key, so the website can store data for X minutes in cache without it being kicked out.
There is also a new call for ClearCache that takes that same cacheKey parameter and clears the cache.
The SaveRecord method has a parameter that will enable a custom cacheKey to be cleared.
What Happens without Custom Cache Keys
If you do NOT specify a custom cache key on your calls to SearchRecords, the system will follow these rules for cache:
Content is cached for 1 minute on a sliding scale. This mean if the cache is accessed within 1 minute, it's potential time in cache will be extended by another minute.
Cached Content is checked for validity every 1 minute. This means that we will only check in the database to see if a cache entry has expired every 1 minute (not on every request), so cache will be less likely to be cleared from memory.
Normally, data in UGC is cached based on the Content Definition it came from for about a minute. This means that changes to data may not appear in the system for about a minute by default.
If you want to take control of the cache on a given set of records in UGC, you can do this by using custom cache keys.
For instance, if you are showing a list of videos for a given user and you want that list to be updated when the user adds a new one, this is how you would do that:
- Pick a cache key that is related to the user and uniquely identifies the set of records.
- For instance, a good cache key might be "[UserID]_Videos" .
- This ensures that a different cache key will be used for each users, and it will be unique to the videos list as well.
- Note that Agility takes care of any searching, paging or sorting parameters.
- You only need to worry about your set of records as a whole.
- Use the cache key when make calls to SearchRecords
- Set the CustomCacheKey value on the SearchArg object that you pass to the SearchRecords call
- Use the cache key when you make calls to SaveRecord on records in the videos list.
- There is an optional 3rd parameter to the SaveRecord method which is the same custom cache key that you used.
- When you do this, the cached items for that user will be cleared.
- Use the ClearCache method if necessary.
- Pass the same cache key string to ClearCache at any time to clear the cache on demand. You might want to do this if you are deleting the user or some other operation where you want to remove the cache.
Remember, if you do not use a custom cache key, your UGC data will be cached on the server for about a minute on a sliding scale, meaning, if you don't change the data for a given UGC content definition, it will stay in cache.