Magnus Rahl
Aug 14, 2017
visibility 3977
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
Optimizely Graph - Provisioning, User Management & Developer Instances

Upgrading to Optimizely CMS 13 marks a major architectural shift as Optimizely Graph takes over as the central query and delivery engine, retiring...

Scott Reed | Sep 28, 2026

An (unofficial) MCP server for Optimizely Data Platform (ODP)

I wanted to ask Claude some questions about session setup data in Optimizely Data Platform (ODP) without writing GraphQL every time. There's no...

Jacob Pretorius | Sep 28, 2026

Admin UI for Optimizely SaaS CMS Integrations Without Extra Tools: Preview-Based Dashboards, OCP UI Extensions and Keeping Them Private

On PaaS we extended the CMS UI with custom admin panels; SaaS CMS has no such hooks. Here is a workaround: an admin UI for external content...

Szymon Uryga | Sep 27, 2026 |

Personalisation in CMS 13 when you go headless: variations in the CMS, decisions in Experimentation

Back in February I wrote about personalisation in CMS 13 using Audiences . Everything in that post still holds, with one condition I should have ma...

Minesh Shah (Netcel) | Sep 24, 2026