Implement Caching in the Application-Server and Storage Layers

Learning Objectives

After completing this unit, you’ll be able to:

• Explain the caching options for the application-server layer.
  
• List two types of content for which B2C Commerce uses caching.
  
• Explain the caching options for the storage layer.
  
• Explain how Page Designer and content slots use remote includes.
  

Cache Data at the Application-Server Layer

The app server, which forms the middle layer, handles endpoints that serve dynamic information, such as consumer data or cart information. This data can’t use page caching. The application, however, performs expensive calculations on those pages and caches the results to reduce the overall processing time of the dynamic request.

Cache Configuration as Code

Configuration as code is a practical approach for supporting multiple brands in multiple countries. Store the configuration in JSON files and extend it through brand- and country-specific overrides. Reading a JSON file and merging JavaScript objects isn’t an expensive operation, but it’s frequent enough to consume lots of processing time. Caching the configuration for each brand and country combination avoids recalculating for every request and remote include.

Apply Request Caching

Use request caching to store data inside a module in a single request. If the data is required later, this approach keeps its state. Caching saves the data in the request, including the associated logic. This approach works well when marketing wants to save a shopper’s selected store but doesn’t want developers to access the raw data directly. The module saves the store ID internally and exposes methods only to return the store object or perform actions with the store, hiding the implementation details and keeping them in a single, central place.

Use request.custom to save and read a small piece of data.

Use the Custom Cache

The custom cache stores a limited amount of information. Because that information isn’t shared across app servers, it isn’t synchronized. Use this method to save the intermediate results of expensive operations that happen within dynamic requests, or operations that run frequently.

Optimize Builds with the File Cache

Use the file cache for build-time optimizations to:

• Generate templates for projects by using template languages other than ISML.
  
• Optimize development code.
  
• Create environment-specific configurations.
  

Cache Shopper Data in Sessions

Sessions store small pieces of temporary shopper information for the duration of a browsing session, such as a selected store or data used for dynamic customer group assignment.

• Use session.custom when collecting data to build dynamic customer groups. Use this option sparingly, because it can consume many system resources.
  
• Use session.privacy when not collecting data to build dynamic customer groups. This option doesn’t trigger customer-group updates and consumes fewer resources, with the and the system clears the data cleared when the shopper logs out of their account.
  

Cache Static Content

Use static content caching for image, style-sheet, and client-side JavaScript files that the browser downloads and consumes. B2C Commerce uses two caches for different kinds of content. You configure and invalidate each separately.

• Page cache, covered in the previous unit
  
• Static content cache
  

The origin server delivers static content, and the enterprise content delivery network (eCDN) caches it. Manage this content directly in the environment or include it in the code. When you manage it directly, the build process often generates it. After this content resides on the server, the server delivers it as-is, and it can’t contain dynamically calculated information.

Manage the static content cache in Business Manager: Administration | Sites | Manage Sites | Global Static Cache (or the Cache tab for site settings).

Use the Storage Layer

The storage layer is where custom objects live. Use custom objects for data that persists across server operations, or as intermediate storage for data that background jobs process later.

• You can import and export custom objects.
  
• You can write to and read custom objects.
  
• Custom objects are persistent and consistent across all application servers.
  

Use custom objects sparingly. Because the database stores custom objects, the objects traverse all architectural layers, which negatively impacts performance.

Monitor Control Endpoints Holistically  

Shoppers spend most of their time on these pages, each of which translates into a controller endpoint.

Getting these pages to high cache-hit rates and fast response times takes attention. The numbers don’t always indicate a positive shopper experience.

The storefront application generates links to product variants on product-list pages (PLPs), while the product-detail page (PDP) redirects to the primary product data. This redirect leads to fast PDP metrics, because each call is effectively two requests:

• A request to the variant that responds with a fast redirect
  
• A request to the PDP
  

The average includes the duration of each request independently, not as the combined pair of redirect plus page load. The PDP is slow, and it uses an additional costly redirect. Other situations also adversely impact average response time, so review performance holistically instead of focusing on a single indicator.

The percentage of processing time value, for example, is a good indicator that you can use to improve page caching or optimize processing times.

Avoid Common Pitfalls

Here are some common pitfalls and how to handle them.

Here are the current guidelines for primary storefront controllers. For the cache-hit ratio, even a few percentage points lower can slow the loading of search result pages and reduce scalability. Use the Reports & Dashboards tool to identify endpoints with a 100 percent cache-miss rate. See if there’s a way they can use cache, too. Primary controller names can vary by customization.

Display Content with Page Designer and Content Slots

Here’s how Page Designer and content slots, which are key content display methods, use remote includes.

Configure Page Designer Remote Includes

When PageMgr.renderPage() renders a Page Designer page, the rendering process uses two nested remote includes.

• SYSTEMPage-Include: Determines the visibility fingerprint of the page and its components based on schedules, customer groups, or other visibility settings. It passes the visibility fingerprint to the second-level remote include.
  
• SYSTEMPage-Render: Invokes the render function to render the page. Based on different visibility settings, the system caches each page variation separately.
  

Serve Content Slots in Remote Includes

The storefront application serves content slots within remote includes for independent cache control. Directives in the rendering template control the caching for the slot content. The application automatically recalculates the slot configuration to show, regardless of the cache settings in the rendering template, through an additional dynamic include.

Next

In this unit, you learned how to maximize application performance using caching in the application-server and storage layers. Next, learn how to troubleshoot common performance issues.

Resources

• Salesforce Help: Content Cache
• Trailhead: Headless Implementation Strategies for Salesforce B2C Commerce (See the Implement a Content Delivery Network and Caching unit.)
• Trailhead: Salesforce B2C Commerce Page Designer for Developers