Magnus Rahl
Aug 14, 2017
visibility 3968
star star star star star star
(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

error Please login to comment.
Latest blogs
Composition Over Inheritance: Why Your Content Contract Is Not a Base Class

Inside the structural conformance pattern in SaaS CMS — from server-side inheritance to pipeline governance. A contract in Optimizely SaaS CMS is...

Vipin Banka | Sep 19, 2026

Optimizely Opti ID Integration: Why the API Key Was Missing from the DXP Management Portal

While working on an Optimizely CMS 12 Opti ID integration recently, we ran into an issue that initially appeared to be related to SSO authenticatio...

Madhu | Sep 18, 2026 |

Extending a Contract: What You Can Override

Contracts share fields across content types — but not every field setting can be overridden. Push the same contract onto several components, and CM...

Chirag Khanna | Sep 18, 2026 |

Building a Blazor Server UI Inside the Optimizely CMS 13 Admin Shell

What I learned shipping a Blazor Server UI inside Optimizely CMS 13 — Razor components in a NuGet package, the Blazor hub next to MapContent(),...

Stanisław Szołkowski | Sep 17, 2026 |