Commerce provides many settings and tools that you can use to improve response time on the pages as well as provide higher throughput.
All asynchronous operations in Commerce are performed using the Linux
cron command. See Configure and run cron to configure it correctly.
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 mode in production, 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.
Reindexing on MariaDB 10.4 and 10.6 takes more time compared to other MariaDB or MySQL versions. We suggest modifying the default MariaDB configuration setting, which is described in the installation prerequisites.
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.
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 Magento Open Source User Guide for more information.
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 Magento Open Source User Guide for more information.
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
set command writes the following to the
... '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
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 Adobe Commerce User Guide for more information.
This option is available only if Backorder with any mode is activated.
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:
|Grid Settings||Asynchronous indexing||Enable|
|CSS Settings||Minify CSS Files||Yes|
|Template Settings||Minify HTML||Yes|
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, Adobe 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.
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.
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
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
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
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.