Introduction
Platform cache in Salesforce provides a powerful and efficient way to improve application performance. Firstly, platform cache enhances performance by storing frequently accessed data in memory. Moreover, it reduces database queries and subsequent latency, resulting in faster response times. Additionally, platform cache enables seamless data sharing across multiple users and requests. Furthermore, it optimizes the execution of complex computations, boosting overall application speed. Salesforce can significantly enhance the performance and scalability of your applications.
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 delve into further details:
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.
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.
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. Overall, it 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.
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 Is Slower Than Getting Data from the Org and Session Cache.
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);
FAQ s
1.How to clear cache memory in Salesforce?
- In Salesforce App, tap the User Profile Avatar (upper left corner) | select Settings.
- Tap Advanced.
- Tap Clear Cached Data.
- Force quit Salesforce App, then open the App & pull to refresh on pages to check for your changes.
2.How do I clear my cache performance?
- Open Google Chrome.
- Click the menu button ⋮ > More Tools > Clear browsing data.
- On the Clear browsing data window, select which time range you want to clear.
- Put a check beside Cookies and other site data and Cached images and files, and then click Clear data.
For Mor Blogs: Click Here
Author Bio
