Welcome back !!! We came back in 2020 after a great success of Apex Hours in 2019. In our very first session of 2020 we will talk about Platform Cache in Salesforce. In this session we will talk about how to Boost your app‘s performance significantly and Understand which kind of data to put in the cache. Know the obstacles when you use to the platform cache and prepare for cache misses and unexpected results. In post/session we will learn about
- Learn using the platform cache can boost your app‘s performance significantly
- Understand which kind of data to put in the cache
- Know the obstacles when you use to the platform cache and prepare for cache misses and unexpected results
What is Platform Cache ?
Platform Cache is a memory layer that store’s Salesforce session and org data for later access. “Platform Cache” is just like a RAM for your app. With Platform Cache, your applications can run faster because they store reusable data in memory. “Platform Cache” is used to to store Static Data, complex computations and Frequently used data
Type of Platform Cache
1) Org Cache :- Org wide data for anyone in the org
2) Session Cache :- Data for a specific user stored up to 8 hours
Key Concepts
Let see the key concept of Platform Cache in Salesforce.
- Simple & temporary Key-Value-Storage (Map)
- Quite Easy to implement ANY cache strategy
- => but Fairly Easy to design a GOOD, sustainable strategy
- By default VISIBLE and MUTABLE
- => but can be RESTRICTED and set to IMMUTABLE
Which kind of data to put in the cache
- PREPARABLE – REUSABLE
- Static: Not changing frequently
- Frequently needed in operations
- Expensive to get (or keep) (in terms of system limits)
- e.g. Taxonomies, Schedules, Mappings, Conversion Rates, etc.
Considerations.
Where‘s the catch?
- It‘s still a cache, not a database.
- It is short lived and per default visible and mutable
- Understand the key concepts of the platform cache (in particular TTL, LRU)
- Expect the cache to fail you.
- What’s your strategy to invalidate cache?
- The Cache will go away… Schedule a Cache Rebuild < TTL
- Cached items will be pushed out… Use the CacheBuilder interface
- Cached data goes stale… Rebuild From Triggers
- Cached items must adhere to the 100kB size limits Reduce memory footprint by using Apex Classes instead of sObject or reduce the number of queried fields
- Don‘t use the cache as a fast, limit-free database.
- Don‘t use it as temporary storage for transactional data
- No items larger than 100kB
- Cached Items are not persisted – don‘t rely on them being there.
- Unless flagged as immutable, don’t rely on the integrity of cached items
Best Practices :-
- Cache lists or maps of objects rather than single objects.Tradeoff: Better performance of fewer, larger operations vs. 100kB item size limit
- Use a wrapper class to reduce sObject overhead
- Use the fully qualified name of your cache partition
- Consider using the ‘immutable‘ flag and the visibility enum
Here is recording of session.
Here is Agenda of session :-
- Concepts
- Use cases and data worth caching
- Implementation as a key /value storage
- Implementation as read-through Cache
- Considerations
Here is PPT of session.
Further Reading
- Developer Documentation: bit.ly/cachedoc
- Trailhead: bit.ly/cachetrail
- Session Code: github.com/dstdia/PlatformCache/
- Keir Bowden’s blog post: bit.ly/cache-buzzard
- Josh Kaplan‘s blog post: bit.ly/cache-sfblog
- Amit Chaudhary: http://bit.ly/cache-amit
Please note that we have limit of 300 attendees that can join the online sessions. However, recording will be posted on our YouTube channel. Make sure to subscribe our YouTube channel to get notification for video upload.
Bookmarks our “Session in 2020” page for all upcoming and old sessions of 2020. Let us know which topic you want learn next in ApexHours.
Sharing is Caring so Share with your friends
Thanks,
Salesforce Apex Hours