Steps to Optimize the Adobe Commerce Performance

When users experience a slow or unresponsive site, it affects conversion. We recommend
following these steps to optimize the Magento speed on Adobe Commerce cloud infrastructure implementation:

• Assess the problem
• Measure performance
• Identify the part of the system critical for performance
  improvement
• Modify part of the system to remove the
  bottleneck
• Measure the performance after modification
• If better, adopt it or revert

Recommendations to Improve Adobe Commerce Performance:

• AEM with Adobe Commerce infrastructure Geographical location

When developing pages, the initial provisioning of the two different infrastructures
should be hosted within the same AWS (or Azure) Region to reduce latency between the AEM publisher and Adobe
Commerce GraphQL.

The geographical location of both clouds should also be close to the majority of your
customer base so that client-side GraphQL requests are provided from a location that is close to the majority of
your clients.

• Adobe Commerce GraphQL caching

Certain calls made by the user’s browser or AEM publisher to Adobe Commerce’s GraphQL
will be cached in Fastly. Cache queries are often those that contain non-personal data and are unlikely to change
frequently. For example, categories, categoryList, and products.

Those that are explicitly not cached are those that change often and, if cached, could
endanger personal data and site functionality, such as cart and customerPaymentTokens inquiries.

Multiple inquiries can be made in a single GraphQL call. It is crucial to note that if
you specify one question that Adobe Commerce does not cache with several other queries that are not cacheable, Adobe
Commerce will skip the cache for all queries in the request.

Developers should keep this in mind while merging numerous queries to avoid accidentally
bypassing potentially cacheable queries.

• Catalog Flat Table:

It is not recommended to utilize flat tables for items and categories. Because using this
outdated feature can cause performance degradations and indexing concerns, the flat catalog should be disabled via
the Adobe Commerce admin, in the storefront area.

Some third-party modules and customizations do require flat tables to function properly;
it is advised that an evaluation be performed to understand the implications and dangers of having to use flat
tables when opting to employ these extensions or customizations.

• Fastly origin shielding

Fastly origin shielding is disabled by default. The goal of Fastly’s origin shielding is
to reduce traffic to the Adobe Commerce origin: when a request is received, a Fastly edge location (or “point of
presence” / POP) scans for and provides cached material.

If it isn’t cached, it moves on to the Shield POP to see if it’s cached there (if the
content has previously been requested even from another global POP, it will be cached). Finally, if it is not cached
on the Shield POP, it will travel only to the Origin server.

Fastly origin shielding can be activated in the Fastly configuration backend settings of
your Adobe Commerce admin account. For optimal performance, select a shield location that is close to your Adobe
Commerce origin data center.

• Fastly image optimization

When you enable Fastly origin shielding, you may also activate Fastly Image Optimizer.
Where product catalog images are stored on Adobe Commerce, this service allows you to offload all resource-intensive
product catalog image transformation processing onto Fastly and away from the Adobe Commerce origin.

End-user response times for page load times are also improved since pictures are changed
at the edge location, which decreases latency by reducing the number of queries back to the Adobe Commerce
origin.

Fastly Image optimization can be enabled by selecting “enable deep image optimization” in
Fastly setup in admin, but only after your origin shield has been active. Fastly image optimization will definitely
help you in Adobe Commerce
SEO optimization.

• Unused modules should be disabled:

Many modules become redundant and are not used when running Adobe Commerce headless, only
delivering queries through the GraphQL endpoint, and no front-end shop pages are delivered directly from Adobe
Commerce.

By eliminating unnecessary modules, your Adobe Commerce code base becomes smaller and
less complex, perhaps improving performance. Adobe Commerce modules can be disabled using composer. Which modules
can be disabled depending on the needs of your site, so no recommended list can be provided because each customer’s
Adobe Commerce implementation is unique.

• Activation of MySQL and Redis connections

MySQL and Redis Slave connections are not enabled by default in Adobe Commerce on the
cloud. This is due to the fact that these settings are only appropriate for customers that anticipate a heavy
load.

With slave connections enabled, the cross-AZ (cross-Availability Zones) delay increases,
hence this configuration actually affects the performance of an Adobe Commerce on cloud instance if the instance
only receives regular demand levels.

If the Adobe Commerce instance is expecting heavy traffic, enabling master-slave for
MySQL and Redis will improve performance by distributing the load on the MySQL Database or Redis across multiple
nodes.

Enabling Slave Connections will, on average, slow down performance by 10-15% in
circumstances with a normal load. However, in clusters with high load and traffic, there is a 10-15% performance
improvement. As a result, it is critical to load-test your environment with projected traffic levels to determine
whether this configuration would benefit your performance times under pressure.

To enable/disable slave connections for MySQL and Redis you should edit your
.magento.env.yaml file to include the following:

Redis slave connections should not be enabled for scaled architecture (split architecture
– see below), as this would result in errors. It is alternatively advised to create L2 caching for Redis in the case
of a split architecture.

• Moving to a cloud-scaled (split) architecture for Adobe Commerce

If, after all of the preceding setups, load test results or real infrastructure
performance analysis show that the load levels to Adobe Commerce are constantly maxing out CPU and other system
resources, then a shift to a scaled (split) architecture should be explored.

A basic Pro architecture has three nodes, each with its own comprehensive tech stack. By
moving to a split-tier design, this reduces to a minimum of 6 nodes: three for ElasticSearch, MariaDB, Redis, and
other core services, and three for web traffic processing (PHP fpm and NGINX).

With split tier, there are more scaling options: core nodes containing databases can be
scaled vertically; web nodes can be scaled horizontally and vertically, providing a great deal of flexibility to
expand infrastructure on demand for set periods of high load activity and on nodes where extra resources are
required.

Hope this post will help you in Adobe Commerce Performance
Optimization. If you still need any help, Hire a Dedicated
Magento Developer and get a Free Trial For 8
Hours, also you can reach us at info@vihadigitalcommerce.com.