Or lock or no lock – that’s the question.
This is the second part of the series on how can you improve the performance of Episerver Commerce site – or more precisely, to avoid the deadlocks and 100% CPU usage. This is not Commerce specific actually, and you can apply the knowledge and techniques here for a normal CMS site as well.
It’s a common and well-known best practice to store the slow-to-retrieve data in cache. These days memory is cheap – not free – but cheap. Yet it is still much faster than the fastest PCIe SSD in the market (if your site is running on traditional HDD, it’s not even close). And having objects in cache means you won’t have to open the connection to SQL Server, wait for it to read the data and send back to you – which all cost time. And if the object you need is a complex one, for example a Catalog content, you will also save the time needed to construct the object. Even if it’s fast, it is still not instantaneous, and it will cost you both memory and CPU cycles. All in all – caching is the right way to go. But how to get it right?
One common mistake for to have no lock when you load the data for the first time and insert it into cache.
Continue reading Episerver Commerce performance optimization – part 2
I ran into this problem recently and while in the end it’s quite simple issue (Everything is simple if we understand it, right?), it costed me quite many hairs in the process – as it involved debugging with 3 solutions – Find.Commerce (where the problem appears), Commerce (where the router does the work), CMS Core (where the routers are handled). It was both fun, and confusing.
The problem as a customer has this code in an initialization module:
var contentLoader = ServiceLocator.Current.GetInstance<IContentLoader>();
var referenceConverter = ServiceLocator.Current.GetInstance<ReferenceConverter>();
var firstCatalog = contentLoader.GetChildren<CatalogContent>(referenceConverter.GetRootLink()).FirstOrDefault();
var partialRouter = new HierarchicalCatalogPartialRouter(() => SiteDefinition.Current.StartPage, firstCatalog, false);
Continue reading Find indexing job + HierarchicalCatalogPartialRouter: A note
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
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
… 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
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
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?
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!
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