�۶���Ƶ

Configuration best practices

Commerce provides many settings and tools that you can use to improve response time on the pages as well as provide higher throughput.

Cron Jobs

All asynchronous operations in Commerce are performed using the Linux cron command. See Configure and run cron to configure it correctly.

Indexers

An indexer can run in either Update on Save or Update on Schedule mode. The Update on Save mode immediately indexes whenever your catalog or other data changes. This mode assumes a low intensity of update and browsing operations in your store. It can lead to significant delays and data unavailability during high loads. We recommend using Update on Schedule for performance purposes, because it stores information about data updates and performs indexation by portions in the background through a specific cron job. You can change the mode of each Commerce indexer separately on the System > Tools > Index Management configuration page. The Customer Grid index must always be set to the Update on Save mode.

Caches

When you launch your store in production, activate all the caches from the System > Tools > Cache Management page. We highly recommend using Varnish, as it is an efficient production page cache solution.

Asynchronous email notifications

Enabling the “Asynchronous email notifications” setting moves processes that handle checkout and order processing email notifications to the background. To enable this feature, go to Stores > Settings > Configuration > Sales > Sales Emails > General Settings > Asynchronous Sending. See Sales Emails in the Admin User Guide for more information.

Asynchronous order data processing

There can be times when intensive sales on a storefront occur at the same time that Commerce is performing intensive order processing. You can configure Commerce to distinguish these two traffic patterns on the database level to avoid conflicts between read and write operations in the corresponding tables. You can store and index order data asynchronously. Orders are placed in temporary storage and moved in bulk to the Order Management grid without any collisions. You can activate this option from Stores > Settings > Configuration > Advanced > Developer > Grid Settings > Asynchronous indexing. See Scheduled Grid Updates in the Admin User Guide for more information.

Asynchronous configuration save

For projects with a large number of store-level configurations, saving a store configuration can take an inordinate amount of time or result in a timeout. The Async Config module enables asynchronous configuration saves by running a cron job that uses a consumer to process the save in a message queue. AsyncConfig is disabled by default.

You can enable AsyncConfig using the command-line interface:

bin/magento setup:config:set --config-async 1

The set command writes the following to the app/etc/env.php file:

...
   'config' => [
       'async' => 1
   ]

Start the following Consumer to begin processing the messages in the queue on a first-in-first-out basis:

bin/magento queue:consumers:start saveConfigProcessor --max-messages=1

Deferred stock update

In times of intensive sales, Commerce can defer stock updates related to orders. This minimizes the number of operations and speeds up the order placement process. However, this option is risky and can only be used when Backorders are activated in the store, because this option can lead to negative stock quantities. This option can bring significant performance improvement on Checkout flows for stores that can easily re-fill their stock on demand. To activate deferred stock updates on your site, go to Stores > Settings > Configuration > Catalog > Inventory > Product Stock Options > Use Deferred Stock Update. See Managing Inventory in the �۶���Ƶ Commerce User Guide for more information.

Client side optimization settings

To improve the storefront responsiveness of your Commerce instance, go to the Admin in Default or Developer mode and change the following settings:

Stores -> Configuration -> Advanced -> Developer:

When you activate the Enable JavaScript Bundling option, you allow Commerce to merge all JS resources into one or a set of bundles that are loaded in storefront pages. Bundling JS results in fewer requests to the server, which improves page performance. It also helps the browser cache JS resources on the first call and reuse them for all further browsing. This option also brings lazy evaluation, as all JS is loaded as text. It initiates analysis and evaluation of code only after specific actions are triggered on the page. However, this setting is not recommended for stores where the first page load time is extremely critical, because all JS content will be loaded on the first call.

Bundling tips

Customer segments validation

Merchants that have a large number of customer segments may experience significant performance degradation with customer actions, such as customer login and adding products to the cart.

Customer actions trigger a validation process for customer segments, which is what can cause performance degradation. By default, �۶���Ƶ Commerce validates each segment in real-time to define which customer segments are matched and which are not.

To avoid performance degradation, you can set the Real-time Check if Customer is Matched by Segment system configuration option to No to validate customer segments by a single combined condition SQL query.

To enable this optimization, go to Stores > Settings > Configuration > Customers > Customer Configuration > Customer Segments > Real-time Check if Customer is Matched by Segment.

This setting improves the performance of customer segment validation if there are many customer segments in the system. However, it does not work with split database implementations or when there are no registered customers.

Database maintenance schedule database

We recommend performing periodic database backups for your Staging and Production instances. Due to the I/O intensive nature of backup operations, you may encounter slower backups and potential issues. Running database processes for multiple environments at the same time may potentially run slower due to contention for available resources.

For better performance, schedule your backups to run in succession, one at a time, at off-peak times. This method avoids I/O contention and reduces time to complete, especially for smaller instances, larger databases, and so on.

For example, we recommend scheduling a backup of your Production database followed up by the Staging database when your stores encounter lower visits.

Limit number of products in grid

To improve product grid performance for large catalogs, we recommend limiting the number of products in the grid with the Stores > Settings > Configuration > Advanced > Admin > Admin Grids > Limit Number of Products in Grid system configuration setting.

This system configuration setting is disabled by default. By enabling it, you can limit the number of products in the grid to a specific value. Records Limit is a customizable setting that has a default minimum value of 20000.
When the Limit Number of Products in Grid setting is enabled and the number of products in the grid is greater than the record limit, then the limited collection of records is returned. When the limit is reached, the total records found, number of selected records, and pagination elements are hidden from the grid header.

When the total number of products in the grid is limited, it does not affect product grid mass actions. It only affects the product grid presentation layer. For example, there is a limited number of 20000 products in the grid, the user clicks on Select All, selects the Update attributes mass action, and updates some attribute(s). As a result, all products are updated, not the limited collection of 20000 records.

The product grid limitation only affects product collections that are used by UI components. As a result, not all product grids are affected by this limitation. Only those that are using Magento\Catalog\Ui\DataProvider\Product\ProductCollection.
You can limit product grid collections on the following pages only:

If you do not want your product grid to be limited, we encourage you to use filters more precisely for the result collection to have fewer items than Records Limit.