Performance improvements

Version: 10.3

Performance improvements in Sitecore Commerce Connect include:

  • Immediate or delayed bucket synchronization. When a new item is created in a bucket, it is immediately placed in the root folder. In order to move it into the right place, you must synchronize the bucket. You can do this by: 

    • By synchronizing a single product, which can immediately be moved to the right place in the bucket. This is done by calling SynchronizeProduct as a single operation from BucketManager.MoveItemIntoBucket(entityItem, root);

    • By doing a bulk synchronization. This is done by calling the SynchronizeProducts or SynchronizeProductList, which can, however, result in the creation of many new items that must be synchronized. When doing bulk synchronizing, it is faster to delay the bucket synchronization until all new product items have been processed. To further reduce the time spent synchronizing the products bucket, a temporary bucket is used for new product items. The temporary bucket is synchronized after all products have been processed and the bucket content is moved to the main bucket. This will eliminate the time spent touching all existing items in the bucket, which could be significant, for example, adding 1000 new product items to a bucket with 1,000,000 product items, will touch 1,001,000 items to make sure they have not changed.

    For more information on how to enable delayed bucketing, see Delayed bucket synchronization.

  • Multithreaded synchronization. A single thread is, by default, created to synchronize products, manufacturers, types, resources, divisions, and specifications in parallel. The threads are created for each repository being synchronized. You can configure the number of threads to use in the Sitecore.Commerce.Products.config file. The default is 1.

    RequestResponse
    <setting name="ProductSynchronization.NumberOfThreads" value="8" />
    Note

    Due to issues in Sitecore CMS, using more than 1 thread can result in a SQL server deadlock situation, which is why the default configuration only specifies 1 thread.

  • Disabling indexing, events, and caching. Triggering item events as well as indexing is disabled while synchronizing in order to conserve resources and avoid indexing before synchronization is complete. Indexing is turned on after synchronization has finished. For more information, see Indexing.

  • Reading product data once and processing it in multiple pipelines reduces the number of calls between Sitecore and the external systems. All product entities in Connect are synchronized using their own pipelines, which naturally lends itself to reading the data from the external system in the individual pipelines. In this case, synchronizing a single product can amount to a fair amount of calls between the systems and each call takes time and resources. The design does not prevent product data to be read once initially and passed on to the individual subpipelines for processing, reducing the number of calls between the systems.

  • Resources can be located externally. Resources in Sitecore are stored as media items in the media library. Media items are binary blobs and can be rather large and time consuming to import into Sitecore and for this reason, you can either import resources into the Sitecore media library or simply refer to them externally. If resources are imported, they are stored in a bucketed folder called Products under the media library. If not imported, they can be referred to by a URI stored on the resource reference item. The default implementation of Connect supports both scenarios.

Do you have some feedback for us?

If you have suggestions for improving this article,