Episerver Commerce performance optimization – part 1

This is a first part of a long series (which have no planned number of parts) as the lessons I learned during trouble shouting customers’ performance problems. I’m quite of addicted to the support cases reported by customers, especially the ones with performance problems. Every time I jump into such support case, I’ll be with less hairs, but I also learn some new things:  Implementations are different from cases to cases, but there are some common mistakes which will hurt your website performance. This series will try to point out those mistakes so you get your performance gain, for (almost) free:

Mistake 1: Loading to much content

It’s easy to load contents, especially with the new content APIs. Given an universal ContentReference, you can load a content with a simple line of code. By default, the loaded content is cached, so you might think it’s cheap, or even free to load a content. Think again.

Continue reading “Episerver Commerce performance optimization – part 1”

Speed up your catalog entries indexing

Even with the raising popularity of FindCommerce, I suspect that many Commerce customers are still using the search provider system, as it comes with an undeniable benefit: It can be used within Commerce Manager. And while I suspect a majority of you have the eventual indexing turned on (aka the entry will be indexed as soon as it’s changed), many still index the entries on demand. Aka manually, or periodically via scheduled job.

We received a report from a customer recently as the indexing timeout, as he was indexing a large amount of entries (about 250.000 entries on 8 catalogs). When we looked into the problem, we discover a possible improvement which is almost free for you.

Continue reading “Speed up your catalog entries indexing”

Too much saves will kill you

… or at least, your website performance!

Recently I worked on two support cases from our customers as they see SQL Server errors, such as “System.Data.SqlClient.SqlException (0x80131904): The INSERT statement conflicted with the FOREIGN KEY constraint “FK_ShipmentEx_Shipment”. The conflict occurred in database “dbCommerce”, table “dbo.Shipment”, column ‘ShipmentId’“, or “System.Data.SqlClient.SqlException (0x80131904): The MERGE statement attempted to UPDATE or DELETE the same row more than once. This happens when a target row matches more than one source row. A MERGE statement cannot UPDATE/DELETE the same row of the target table multiple times. Refine the ON clause to ensure a target row matches at most one source row, or use the GROUP BY clause to group the source rows.

These errors happened randomly, during the high load times – it seems to be affected by the concurrency level.

What was wrong? and why?

It took me a good amount of time, and good amount of hairs, too. The actual error is another one, and the one above is just the “by product”.

The cart system in Episerver Commerce suffers from a design flaw: it shares (almost) everything with the purchase orders. ShoppingCart is just another metaclass extended OrderGroup, so it’ll use the same OrderGroup, OrderForm, Shipment, LineItem and OrderAddress tables in the database, like PurchaseOrder and PaymentPlan. At first, it seems to be reasonable approach. But when you have hundreds, or thousands of customers visiting your website (and you would be happy to see that ;)) – problems start to appear.

Continue reading “Too much saves will kill you”

You can now finally hate workflows

For a good long amount of time, workflows have been an essential part of Episerver Commerce (and even before that, Mediachase eCF). Once you get into order system, you just can’t escape workflows – because you need them. They handle many – if not all things, from validating items, checking inventories (to make sure that you are not selling something out-of-stock, or just discontinued (think of Galaxy Note 7, poor little shiny phone)), applying promotions, calculating taxes, process payments, and finally adjust inventories (yay, a customer places an order, let’s ship to him as soon as possible, firstly allocate the goods for him). And workflows are even required by later processing – when you complete the shipments (another happy customer!), or when you issue a return or an exchange (well, let’s keep the customer still happy).

Continue reading “You can now finally hate workflows”

EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?

It can be pretty confusing for new Commerce developers to understand how to work effectively with entries in Commerce. There are many things which represent the same concepts, however they are different and their APIs are not compatible. So which is which and what should you use?

Which is which

    • CatalogEntryDto is the DataSet to represent one or more entries (CatalogEntryDto can of course be empty). Beside the basic information like Name, Code, or MetaClassId, depends on how did you load it, a CatalogEntryDto can contain information about the assets, the associations or the variations (you can specify what to load by using CatalogEntryResponseGroup parameter. CatalogEntryDto, however, does not contain information of the metadata system of an entry – for example, if you add a metafield named “Description” to your entry metaclass – that is not available in a CatalogEntryDto.
      CatalogEntryDto can be loaded or saved by ICatalogSystem methods.

    Continue reading “EntryContentBase, MetaObject, CatalogEntryDto, Entry: which should you use?”

    Catalog Search APIs are for editing only!

    If you are using Catalog Search APIs for any customer-facing features, you are doing it wrong!

    I have seen this problem a couple of times – the search feature on the site is “dead” – it is very slow, and the log file is usually filled with dead lock or timeout error. As it turns out, the search feature was implemented by Catalog Search APIs, which is a big no-no.

    To be clear, there are two builtin APIs related to searching in Episerver Commerce: the “fast” one, which can be done via SearchManager, ISearchCriteria and ISearchResults, is the SearchProvider APIs. It’s the indexed search (strictly speaking, you can make it not “indexed”, but that’s beside the point), and the actual search functions will be provided by providers, like LuceneSearchProvider, Solr35SearchProvider, or FindSearchProvider.

    Continue reading “Catalog Search APIs are for editing only!”

    I was with the EMVPs, and that was a fantastic experience

    If there is anything I regret being an Episerver employee, is that I can’t be an EMVP – the gang of awesome Episerver developers which their contributions are widely recognized by the community (I don’t consider myself to be “awesome”, but I try (to be)). The EMVPs can be seen as the evangelists of Episerver frameworks and technologies, they spread their wisdom, experience and best practices to help developers build better solutions, and they give valuable feedback to us to build better frameworks.

    EMVP Summit is one of special treat Episerver gives to EMVPs, as a recognition for their contributions, and also a chance – directly than ever – for Episerver to listen to the feedback from their distinguish developers. As a software engineer in Commerce development team, I was sent to team up, to talk, to discuss and to socialize with the EMVP (after winning a small competition with my two teammates, and getting a grant from my wife 🙂 ).

    Continue reading “I was with the EMVPs, and that was a fantastic experience”

    Debug .NET memory dump with WinDBG – crash course. Part 1

    If you ask me what had I been doing the last two weeks – then the answer is I was pulling my hairs.  A customer had a problem with their site as the memory hiked up after catalog imports and stayed there “forever” – and in the end it slowed the site down. I jumped in and almost regretted that decision – had to spent days  messing around with WinDBG and memory dumps. In the end – I found the problem and it was fixed. A lot of hairs were loss in progress, but I learned something about WinDBG – and that’s what I’m sharing today.

    WinDBG is probably the most famous tool for debugging stuffs on Windows. Out of the box, it only works with native applications, aka assembly and such – but lucky for us, there are plenty of extensions to allow it to work with .NET application. The “standard” SOS and more advanced extension SOSEX. SOS is included in WinDBG, while you can download SOSEX from here (for 64 bit) or here (for 32 bit) . Download the zip file and extract the dll somewhere.

    WinDBG comes with the Windows SDK, not the standard .NET framework, so you’ll probably need to install it separately from here

    Continue reading “Debug .NET memory dump with WinDBG – crash course. Part 1”

    Why (and when) should you contact Episerver developer support service.

    Today I filed a bug, which I should have filed almost one year ago. I saw it several times, I even had solution for it, but I didn’t think/know it was a bug. It was reported here: http://world.episerver.com/forum/developer-forum/Problems-and-bugs/Thread-Container/2016/9/commerce-catalog-randomly-goes-empty-until-website-restart/  and here http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2016/6/addstaticattributepropertyvalues-object-reference-exception/

    I’ve always wanted to say Episerver products are perfect frameworks and have no bugs at all. But that’s not true. Despite of having very talented developers and dedicated QAs, and a very high requirement for quality (“Quality is non-negotiable”), we still miss to catch some (very few) bugs.

    Continue reading “Why (and when) should you contact Episerver developer support service.”