Quan Mai
Jan 20, 2015
  2035
(0 votes)

Don’t let CatalogEntryFull slows you down.

Just like any EPiServer products, one of main concern of us when developing Commerce is performance. Why many parts of Commerce can be described as “Good enough”, some parts are just acceptable, and I must admit that there’s area where performance need to be improved to meet customer’s expectation.

We are under an intensive performance improvement process which we try to optimize our code to cut out any slow code we can found. And one thing come to my mind when I investigate the impact of CatalogEntryResponseGroup. Let’s see the dotTrace profile for CatalogEntryFull value:  CatalogEntryFull

You can see how insane CatalogEntryFull can do. It’s more than 4000 call to LoadEntryWorker just to load 9 Entry.

The terrible secret behind CatalogEntryFull is when you use it, Catalog system will try to load everything of the CatalogEntryDto, along with associations and children, recursively. The more complex and related your catalog entry is, the slow CatalogEntryFull becomes.

While we recommend to use new content API:s whenever possible, there are still place where Entry/Entries being used, such as when you call CartHelper.AddToCart method. Be sure to use the minimal ResponseGroup which works for you, instead of throw the full-fledge, big and slow CatalogEntryFull.

 

TL, DR; you should avoid CatalogEntryFull if you don’t have too. Use it only you absolutely need it. Use most lightweight CatalogEntryResponseGroup enum that do the work for you. You might need to use several enum combined, such as Assets | Inventory, instead of just going for the bad, ugly and slow CatalogEntryFull.

Jan 20, 2015

Comments

Arve Systad
Arve Systad Jan 20, 2015 11:36 PM

I like what I read!

Every millisecond counts, and especially in solutions with thousands of products, all performance gains are extremely welcome.

Are there plans to get rid of the CatalogEntryDto-style APIs at some point, and let the "de facto product management" go through IContentLoader and other more modern interfaces?

Quan Mai
Quan Mai Jan 21, 2015 03:40 AM

I believe that it's our vision, but it won't happen anytime soon. We would support two API:s at the same time for smoother transition.



By the way, this blog post applies for EPiServer Commerce all version, from 1 R1 to latest nuget package.

Please login to comment.
Latest blogs
Preview multiple Visitor Groups directly while browsing your Optimizely site

Visitor groups are great - it's an easy way to add personalization towards market segments to your site. But it does come with it's own set of...

Allan Thraen | Sep 26, 2022 | Syndicated blog

The Report Center is finally back in Optimizely CMS 12

With Episerver.CMS.UI 12.12.0 the Report Center is finally re-introduced in the core product.

Tomas Hensrud Gulla | Sep 26, 2022 | Syndicated blog

Dynamic Route in ASP.NET Core When MapDynamicControllerRoute Does Not Work

Background Creating one of the add-on for Optimizely I had to deal with challenge to register dynamically route for the API controller. Dynamic rou...

valdis | Sep 25, 2022 | Syndicated blog

404 Error on Static Assets Within an Optimizely plugin

Background With the move to CMS 12 and .NET 5/6, developers are now able to build Plugins and Extensions using Razor Class Libraries (RCL).  These...

Mark Stott | Sep 23, 2022

How to bypass the content creation view in Optimizely

Something that has come up a couple of times in the last few year is feedback from content editors about the editing view that comes up when creati...

Ynze | Sep 23, 2022 | Syndicated blog

Welcome to Optimizely World's New Tech Video Portal

Optimizely, leader in the digital experience realm, has become a wealth of world class SaaS products including Web Experimentation, Full Stack, B2B...

The Developer Marketing Team of Optimizely | Sep 22, 2022