Documentation Adobe Support and Tools Guide

Performance optimization

Last update: September 30, 2026

CREATED FOR:

Admin
Developer

This section provides technical recommendations for preparing Adobe Commerce environments—both Commerce on cloud infrastructure and on-premises—for high-traffic events such as the holiday season.

NOTE

Steps marked (Cloud only) apply to Commerce on cloud infrastructure. Most other recommendations also apply to on-premises deployments.

Optimize Fastly request caching (Cloud only) optimize-fastly-request-caching

Fastly caches responses at the edge to reduce load on your origin server. During peak season, a few configuration checks help you get the most out of that cache, especially when you’re running promotions with tracking parameters or a headless storefront. For the full configuration reference, see Customize cache configuration.

Normalize tracking parameters: During the holiday season, you’re likely to run social and paid campaigns, such as Google Ads, Facebook, and X, that append unique tracking strings to every URL. Each unique string creates a separate cache entry for what’s otherwise the same page, which lowers your cache hit ratio. Add these parameters to the Ignored URL Parameters list in the Fastly configuration in the Adobe Commerce Admin so that Fastly treats them as equivalent.
Confirm that your landing pages are cacheable: Check the x-cache response header on each promotion landing page. A cacheable page returns HIT, or a HIT/MISS pair on subsequent loads. If the header returns MISS, MISS, the page isn’t caching and requires investigation.
Use GET requests for GraphQL queries: If you run a PWA or headless storefront, send GraphQL queries as GET requests with the query included in the URL, rather than as POST requests. Fastly caches only GET requests where the query is part of the URL. A GET request with the query sent in the body isn’t cached.

NOTE

Fastly origin shielding also affects cache performance. For configuration details, see Fastly origin shielding.

Enable Fastly IO (Cloud only) enable-fastly-io

Fastly IO offloads image resizing and format conversion to the Fastly edge network instead of the Adobe Commerce origin. This reduces server load and improves page rendering speed for image-heavy storefronts, a common bottleneck during high-traffic sales periods. For configuration options, see Fastly image optimization.

Before you begin, confirm that origin shielding is configured. Fastly IO requires origin shielding as a prerequisite. For configuration details, see Fastly origin shielding.

To enable Fastly IO:

In the Admin, go to the Fastly Configuration page and select Configure next to Default IO config options.
Confirm that the Fastly IO snippet is enabled.
In the Image Optimization configuration, set Enable deep image optimization to Yes. This setting disables Adobe Commerce’s built-in image resizing and transfers the task to Fastly.
Confirm that the shield location is set correctly. For configuration details, see Fastly origin shielding.

NOTE

Deep image optimization resizes product images only. CMS images, such as banners and content blocks, aren’t affected and continue to use Adobe Commerce’s built-in resizing.

To verify that Fastly IO is working, check the response headers on a product image request:

The x-cache header returns HIT.
The fastly-io-info and fastly-stats headers are populated.
The image URL doesn’t include a /cache/ directory in the path.

Implement Redis L2 cache implement-redis-l2-cache

Implement effective caching practices so that your store performs reliably during peak traffic seasons. Redis L2 cache reduces network bandwidth to Redis by storing cache data locally on each web node. For background on how L2 cache works, see Level two cache.

On Commerce on cloud infrastructure, enable this by setting the REDIS_BACKEND deploy variable. For configuration steps, see REDIS_BACKEND in the Commerce on Cloud Infrastructure Guide. On-premises, configure it directly in app/etc/env.php.

NOTE

Redis is not supported as the L2 cache backend on Adobe Commerce 2.4.9 or later, or on patch releases later than 2.4.5-p16, 2.4.6-p14, 2.4.7-p9, or 2.4.8-p4. On these versions, use VALKEY_BACKEND instead.

Enable MySQL and Redis slave connections (Cloud only) enable-mysql-and-redis-slave-connections

Redis and MySQL slave connections offload read traffic to replica nodes, reducing load on the master connection during high-traffic periods. For configuration steps, see MYSQL_USE_SLAVE_CONNECTION and REDIS_USE_SLAVE_CONNECTION or VALKEY_USE_SLAVE_CONNECTION, depending on your Adobe Commerce version.

Redis slave connections

A Redis slave connection is a read-only connection to a Redis instance, allowing read traffic to be served from a non-master node. Without it enabled, MySQL can suffer a high-load bottleneck. Check New Relic’s APM Overview chart for rising response times as an early sign, then confirm in the Database tab by sorting by most time-consuming transaction to identify slow MySQL SELECT queries. Enable this by setting the deploy variable REDIS_USE_SLAVE_CONNECTION to true.

NOTE

REDIS_USE_SLAVE_CONNECTION is supported only on Staging and Production Pro cluster environments. It is not supported on Starter or Scaled (split) architecture projects. Enabling it on Scaled architecture causes Redis connection errors—use Redis L2 cache instead on that architecture. See Implement Redis L2 cache above.

MySQL slave connections

Enable the MYSQL_USE_SLAVE_CONNECTION flag on Pro cluster environments to direct specific read-only database queries to a slave connection, offloading query execution from the master connection.

CAUTION

Load test before enabling either setting in production. On environments with normal load, slave connections can slow performance by 10 to 15 percent. On environments with heavy, sustained load, they can improve performance by a similar margin. Evaluate under expected peak-season traffic before enabling.

Enable asynchronous order and email processing enable-asynchronous-order-and-email-processing

Use asynchronous processing to queue and execute high-volume order-related operations in the background, reducing frontend latency during peak traffic. This covers three related but distinct settings—see Configuration best practices for an overview.

Asynchronous order placement: The Async Order module marks an order as received, places it in a queue, and processes orders first-in-first-out. It is disabled by default. Enable it from the command line:

code language-none
`bin/magento setup:config:set --checkout-async 1`

Once enabled, order details aren’t available immediately—the order remains queued until the placeOrderProcess consumer verifies it against inventory (enabled by default) and updates it. Before disabling this module, verify that all in-flight asynchronous orders have finished processing. For details, see Checkout performance best practices.

Asynchronous order data processing: Intensive storefront sales and intensive order processing can conflict at the database level. Enabling this setting distinguishes the two traffic patterns, so orders are placed in temporary storage and moved in bulk to the Order Management grid without collisions. This schedules updates, by cron, to the Orders, Invoices, Shipments, and Credit Memos grids, avoiding locks and reducing processing time. For best results, configure cron to run once every minute.

note

NOTE

How you enable this depends on your deployment mode. Adobe Commerce on cloud infrastructure Staging and Production environments run in Production mode by default, where this setting isn’t available through the Admin. In Production mode, run bin/magento config:set dev/grid/async_indexing 1 instead. In Default mode, go to Stores > Configuration > Advanced > Developer > Grid Settings and set Asynchronous Indexing to Enable.

For details, see Scheduled order operations.

Asynchronous email notifications: This setting moves checkout and order-processing email notifications to the background. Enable it at Stores > Configuration > Sales > Sales Emails > General Settings > Asynchronous Sending.

Configure indexers for update on schedule configure-indexers-for-update-on-schedule

Set indexers to run in scheduled mode to avoid database locking and improve responsiveness during frequent catalog updates. For details, see Best practices for indexer configuration.

An indexer can run in Update on Save or Update on Schedule mode.

Update on Save indexes immediately whenever catalog or other data changes. It assumes low update and browsing intensity, and can cause significant delays and data unavailability under high load.
Update on Schedule is recommended for production. It stores information about data updates and reindexes in the background through a dedicated cron job.

Set each indexer’s update mode independently at System > Tools > Index Management.

IMPORTANT

The customer_grid indexer’s supported modes depend on your Adobe Commerce version. On versions earlier than 2.4.8, Customer Grid supports Update on Save only—do not set it to Update on Schedule. On Adobe Commerce 2.4.8 and later, Customer Grid supports both modes and now defaults to Update on Schedule.

Disable and evaluate catalog flat table disable-and-evaluate-catalog-flat-table

The use of flat tables for products and categories is not recommended. This deprecated feature can cause performance degradation and indexing issues. For details, see Flat catalogs.

To disable the flat catalog, go to Stores > Configuration > Catalog > Catalog > Storefront, set Use Flat Catalog Category to No, set Use Flat Catalog Product to No, then click Save Config.

Some third-party modules and customizations do require flat tables to function correctly. Evaluate the impact and risk of continuing to use those extensions before disabling flat tables.

Consider scaled (split) architecture (Cloud only) consider-scaled-split-architecture

If, after applying the preceding configuration and code-level optimizations, load testing or live infrastructure performance still shows CPU and other resources maxed out, consider moving to a scaled (split) architecture. For details, see Scaled architecture.

NOTE

Scaled architecture is available only for accounts with a Pro 48 cluster or greater.

Split-tier architecture uses a minimum of six nodes: three service nodes running OpenSearch or Elasticsearch, MariaDB, and Redis or Valkey, and three web nodes running php-fpm and NGINX.

Service nodes can scale vertically only, by increasing server size (CPU and memory). Because the database cluster is built for high availability, service nodes cannot scale horizontally in a reliable way.
Web nodes can scale both vertically and horizontally, adding web servers to handle increased request volume.

This lets you expand infrastructure on demand for periods of high load, scaling each tier independently. To switch to split-tier architecture ahead of an expected heavy-load period, contact your Adobe Account Team.

recommendation-more-help

support-resources-help-adobe-support-tools-guide