Get Started with Platform Cache
Note
Attention, Trailblazer! Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Salesforce Classic.
Learning Objectives
After completing this unit, you’ll be able to:
- Describe what platform cache is and what it’s used for.
- List the two types of platform cache and give examples of each.
- Describe partitions and how to use them.
What Is a Cache?
A cache is temporary storage. In the computer world, cache is temporary storage for frequently accessed data from a database. Here’s an analogy. Suppose you’re a chipmunk looking for nuts and acorns for dinner. It’s 5:00 and you’re ready to eat. Are you going to use the nuts and acorns stored in your cheeks (cache), or are you going back to the forest to gather more from trees (database)? If you access the temporary cache of food in your cheeks, your dinner is closer and you get to eat it faster! Also, you accomplish your goal more efficiently. A data cache has similar advantages, but for people, not chipmunks.
What Is Platform Cache?
Platform Cache is a memory layer that stores Salesforce session and org data for later access. When you use Platform Cache, your applications can run faster because they store reusable data in memory. Applications can quickly access this data; they don’t need to duplicate calculations and requests to the database on subsequent transactions. In short, think of Platform Cache as RAM for your cloud application.
With Platform Cache, you can also allocate cache space so that some apps or operations don’t steal capacity from others. You use partitions to distribute space. We’ll get to partitions later.
Before We Go Any Further
Let’s pause for a moment for you to request a trial of Platform Cache. By default, your Developer org has 0 MB cache capacity. You can request a trial cache of 10 MB.
To request a trial, go to Setup in your Developer org. In the Quick Find box, enter cache, and then click Platform Cache. Click Request Trial Capacity and wait for the email notifying you that your Platform Cache trial is active. Salesforce approves trial requests immediately, but it can take a few minutes for you to receive the email.
If you don’t have a cache trial, you can still execute cache operations to learn how to use the cache. However, cache storage is bypassed, and retrieved values are null (cache misses).
Okay, now that you’ve requested a Platform Cache trial, let’s learn some more concepts.
When Can I Use Platform Cache?
You can use Platform Cache in your code almost anywhere you access the same data over and over. Using cached data improves the performance of your app and is faster than performing SOQL queries repetitively, making multiple API calls, or computing complex calculations.
The best data to cache is:
- Reused throughout a session, or reused across all users and requests
- Static (not rapidly changing)
- Expensive to compute or retrieve
Store Data That Doesn’t Change Often
Use the cache to store static data or data that doesn’t change often. This data is initially retrieved through API calls from a third party or locally through SOQL queries. If the data changes, cache this data if the values don’t have to be highly accurate at all times.
Examples of such static data are:
- Public transit schedule
- Company shuttle bus schedule
- Tab headers that all users see
- A static navigation bar that appears on every page of your app
- A user’s shopping cart that you want to persist during a session
- Daily snapshots of exchange rates (rates fluctuate during a day)
Store Data Obtained from Complex Calculations
Values that are a result of complex calculations or long queries are good candidates for cache storage. Examples of such data are:
- Total sales over the past week
- Total volunteering hours company employees did as a whole
- Top sales ranking
For clues on where to use Platform Cache, inspect your code. For example, do you currently store app data by overloading a Visualforce view state? These stored values are all candidates for Platform Cache.
Not every use case is a Platform Cache use case. For example, data that changes often and that is real-time, such as stock quotes, isn’t a good candidate for caching. Also, ensure you familiarize yourself with Platform Cache limitations. For example, if your data is accessed by asynchronous Apex, it can’t be stored in a cache that is based on the user’s session.
Cache Allocations by Edition
Platform Cache is available to customers with Enterprise Edition orgs and above. The following editions come with some default cache space, but often, adding more cache gives even greater performance enhancements.
- Enterprise Edition (10 MB by default)
- Unlimited Edition (30 MB by default)
- Performance Edition (30 MB by default)
Note
Platform cache is not available to Professional Edition customers.
Experiment with Trial Cache
You can purchase additional cache for your org. To determine how much extra cache would be beneficial for your applications, you can request trial cache and try it out. Also, request trial cache for Professional Edition before purchasing cache. Use trial cache in your Developer Edition org to develop and test your applications with Platform Cache. When your request is approved, you receive 30 MB of trial cache space (10 MB for Developer Edition). If you need more trial cache space, contact Salesforce.
What Are the Types of Platform Cache?
There are two types of Platform Cache: org cache and session cache.
Org Cache
Org cache stores org-wide data that anyone in the org can use. Org cache is accessible across sessions, requests, and org users and profiles.
For example, weather data can be cached and displayed for contacts based on their location. Or daily snapshots of currency exchange rates can be cached for use in an app.
Session Cache
Session cache stores data for an individual user and is tied to that user’s session. The maximum life of a session is 8 hours.
For example, suppose that your app calculates the distance from a user’s location to all customers the user wishes to visit on the same day. The location and the calculated distances can be stored in the session cache. That way, if the user wants to get this information again, the distances don’t need to be recalculated. Or, you might have an app that enables users to customize their navigation tab order and reuse that order as they visit other pages in the app.
What Are the Performance Gains When Using the Cache?
You might be wondering how much performance your app gains by using Platform Cache. Retrieving data from the cache is much faster than through an API call. When comparing SOQL to cache retrieval times, the cache is also much faster than SOQL queries.
The following chart shows the retrieval times, in milliseconds, of data through an API call and the cache. It is easy to notice the huge performance gain when fetching data locally through the cache, especially when retrieving data in multiple transactions. In the sample used for the graph, the cache is hundreds of times faster than API calls. In this graph, cache retrieval times are just a few milliseconds but appear as almost zero due to the scale used for the time value. Keep in mind that this chart is a sample test, and actual numbers might vary for other apps.
Making API Calls to External Services Is Slower (1) Than Getting Data from the Cache (2).
This next graph compares SOQL with org and session cache retrieval times. As you can see, SOQL is slower than the cache. In this example, the cache is two or more times faster than SOQL for data retrieval in a single transaction. When performing retrievals in multiple transactions, the difference is even larger. (Note that this graph is a sample and actual numbers might vary for other apps.)
Getting Data Through SOQL Queries (1) Is Slower Than Getting Data from the Org and Session Cache (2).
What Are Cache Partitions?
Remember when we mentioned earlier that with Platform Cache you can allocate space using partitions? Let’s talk now about partitions. Partitions let you allocate cache space to balance usage and performance across apps. Caching data to designated partitions ensures that the cache space isn’t overwritten by other apps or by less critical data.
Before you can use cache space in your org, you must create partitions to define how much capacity you want for your apps. Each partition capacity is broken down between org cache and session cache. Session and org cache allocations can be zero, 5 MB, or greater, and must be whole numbers. The minimum size of a partition, including its org and session cache allocations, is 5 MB. For example, say that your org has a total of 10-MB cache space and you created a partition with a total of 5 MB, 5 MB of which is for session cache and 0 MB for org cache. Or you can create a partition of 10-MB space, with 5 MB for org cache and 5 MB for session cache. The sum of all partitions, including the default partition, equals the Platform Cache total allocation.
The following image shows charts of cache capacity and partition allocation. In this example, we haven’t used the cache yet as evidenced by the 0% cache usage (1) and two partitions have been created with equal allocations (2).
Default Partition
You can define any partition as the default partition, but you can have only one default partition. The default partition enables you to use shorthand syntax to perform cache operations on that partition. This means that you don’t have to fully qualify the key name with the namespace and partition name when adding a key-value pair. For example, instead of calling Cache.Org.put('namespace.partition.key', 0); you can just call Cache.Org.put('key', 0);
In the next unit, you’ll create a partition in Setup to get started using Platform Cache!
Resources
Resources in the Apex Developer Guide:
Resources in Salesforce Help: