A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More

Magnus Rahl
Aug 14, 2017
  3602
(8 votes)

Improved Memory Efficiency in Commerce 11.1

TL;DR: Episerver Commerce 11.1 contains improved caching strategies for Catalog Content allowing site implementations to make better use of the available memory.

Caching in the Catalog APIs

Episerver Commerce uses a Content Provider to make catalog data available through the Content API, which is the recommended API to use in site implementations. The Catalog Content Provider uses the low-level catalog DTO and MetaObject APIs to construct the Content instances.

These low-level APIs are also public and have their own cache, which means several representations of the same base data will be cached when loading Content. However, a site implementation built using the Content APIs is unlikely to, at least frequently, use the low-level APIs to access the same catalog data.

Improved Caching Strategies for Content, Relations and Associations

Because of this, in Commerce 11.1 the caching strategies have been changed so that when the low-level APIs are used by the Catalog Content Provider, only the Content is inserted into the cache. Similarily, when using the IRelationRepository and IAssociationRepository APIs, only the high level Relation/Association objects are cached, not the underlying DTOs. If an implementaton uses the low-level APIs directly, the caching strategies are the same as before.

Memory Used Better, Not Necessarily Less

As you may have realized, this doesn't really decrease the memory usage at the time of loading Content from the database, as the DTO and MetaObject will still have to be allocated. The difference lies in how quickly that memory can be recovered and reused. Before this change, the DTO and MetaObject wouldn't go out of scope until they were trimmed from cache, and by the time they were trimmed they may have been promoted to the garbage collection generation 1 or 2 making it harder to recover the memory. With this change, they will go out of scope quickly and can easily be garbage collected, allowing the application to make better use of the available memory, for example holding more Content items in cache and reducing the cache churn.

Aug 14, 2017

Comments

Please login to comment.
Latest blogs
Looking back at Optimizely in 2025

Explore Optimizely's architectural shift in 2025, which removed coordination cost through a unified execution loop. Learn how agentic Opal AI and...

Andy Blyth | Dec 17, 2025 |

Cleaning Up Content Graph Webhooks in PaaS CMS: Scheduled Job

The Problem Bit of a niche issue, but we are building a headless solution where the presentation layer is hosted on Netlify, when in a regular...

Minesh Shah (Netcel) | Dec 17, 2025

A day in the life of an Optimizely OMVP - OptiGraphExtensions v2.0: Enhanced Search Control with Language Support and Synonym Slots

Supercharge your Optimizely Graph search experience with powerful new features for multilingual sites and fine-grained search tuning. As search...

Graham Carr | Dec 16, 2025

A day in the life of an Optimizely OMVP - Optimizely Opal: Specialized Agents, Workflows, and Tools Explained

The AI landscape in digital experience platforms has shifted dramatically. At Opticon 2025, Optimizely unveiled the next evolution of Optimizely Op...

Graham Carr | Dec 16, 2025