The usual suspects — 5 configuration fixes to maximize your peak sales

Too often we forget that regular maintenance is the unsung hero of ecommerce site performance. And one often overlooked aspect of site maintenance is periodically checking for configuration issues. Configuration issues that go unnoticed can evolve into poor site performance — especially right after you’ve installed a patch, implemented a new extension, or made a change to your site.

While configuration issues are typically easy to fix, they can have a negative impact on your site’s performance and security. Your site could crash due to increased traffic to your digital storefront during a promotion or holiday event, slow web pages could lead frustrated customers to exit your site and play right into the hands of a competitor, or it could simply take longer for your team to perform routine maintenance tasks.

How to fix — and prevent — the 5 most common configuration issues for Adobe Commerce sites

The good news is that the five most common configuration issues facing merchants this year are relatively easy to spot and address, especially when you’re aware of the possible symptoms. If you promptly fix these issues now, you can prevent unplanned downtime and lost sales when it counts.

Read on to become an expert on the five most common configuration issues with Adobe Commerce, what they look like, and how to handle them quickly.

Issue 1 – Incorrect patches are installed

Within Adobe Commerce, ece-tools ensure the correct patches are installed for your version of Commerce.

Check that the latest ece-tool module and its dependent modules are installed — using the switch --with-dependencies — to ensure all the required cloud patches are properly installed according to your Adobe Commerce version.

Review the patch list available in the Quality Patches Tool and ensure you’ve applied the performance patches compatible with the version of Adobe Commerce found in this module.

Issue 2 – Poor performance due to inadequate cluster sizing

If your environment is not sized correctly, you may experience poor performance.

Peak season is a crucial time for e-commerce businesses. It brings with it a surge in website traffic, and if you have planned your promotions strategically, you may even be able to anticipate the magnitude of these traffic spikes. However, to ensure a seamless shopping experience for your customers, you might need to consider a temporary cluster upsize, which allows you to allocate more computing resources when handling these traffic surges.

For Adobe Commerce on Cloud Infrastructure customers, implementing a planned upsize is a straightforward process. All you need to do is raise a support ticket in advance with the date range and the required cluster size. Reach out to your dedicated account manager to discuss your current resource consumption and outline your requirements.

For example, let’s assume an Adobe Commerce Pro customer, with daily baseline cluster size of 24 cores — a total of 24 virtual CPUs and 96 GB RAM. If this customer wants to upsize to 96 cores for 7 days for a promotion, the new resources would be roughly 4 times — a total of 96 virtual CPUs and 384 GB of RAM — for just an extra consumption of 504 vCPU days (96x7 – 24x7).

Issue 3 – Performance issues due to overloading origin servers and slower responses

The following checks are important for websites with a default theming approach. But it can be applicable to PWA (progressive web apps) and headless websites too.

1. Normalize unique parameters. During the holiday seasons, you are likely to run digital marketing promotions on different platforms — including Google Ads, Facebook, and TikTok — with unique tracking query strings for each customer. Revise the “Ignored URL Parameters” list in the admin panel to improve cache performance by normalizing these requests.
   
   
2. Ensure your landing pages are cacheable. Review if all the promotion landing pages are cacheable in Fastly. You can check the x-cache header in the response to see if they return any of the following [HIT] or [HIT, HIT] or [HIT, MISS] or [MISS, HIT] for subsequent page loads.
3. GraphQL query caching. For PWA and headless websites, make sure the GraphQL queries are using GET instead of POST whenever applicable.

Issue 4 – Poor system health from not monitoring your traffic using New Relic (Commerce Cloud)

Within Commerce on Cloud Infrastructure, the New Relic observability platform subscription helps seamlessly incorporate the Fastly logs that stream into New Relic in near real-time. This integration enables you to monitor your traffic patterns and trends in real-time through New Relic, empowering you to take corrective actions as necessary.

There are many applications of these logs and how you can utilize them to monitor the system's health, including:

• Identify which countries your web requests originate from.
• Find abusive IP addresses/user agents crawling your website.
• Discover malicious web traffic targeting one of more endpoints of your website.
• Build reports on the device and browser types your customers are using.

For example, let’s say you would like to monitor the source country of your web traffic to ensure it reflects your promotions and customers’ geo locations accurately. You could use the following query to determine your customers’ locations:

SELECT count(*) FROM Log
WHERE cache_status IS NOT NULL
AND project_id = '<YOUR_PROJECT_ID>'
AND (content_type LIKE 'text/html;%' or url LIKE '%graphql%' or url like '%rest%')
FACET geo_country_code
SINCE 7 days ago until today

You can modify the queries depending on your needs, dive deeply into the specific segments, and even create dashboards out of them to track them in one place.

Issue 5 – Slow database performance due to time-consuming database requests

It is important to regularly monitor and review the most time-consuming database transactions in New Relic. If there are significant slow queries or components, investigate how to optimize them.

• New Relic > APM and Services > Select Environment > Databases > Most time-consuming transactions

Furthermore, you can review the mysql-slow.log for the slow queries recorded by the system. These logs can be found in New Relic.

• New Relic > Logs > Filter by filePath:"/var/log/mysql/mysql-slow.log"

Review the MySQL slow query logs and make sure slow queries are not executed frequently.

Find and fix problems faster

All the issues described in this post cause noticeable symptoms that can prompt a technical investigation, and Adobe is working hard to make it easier to detect them before they affect customers and business users.

For a more detailed report on your environment, you can generate a SWAT report. More information about the SWAT tool can be found in the Site-Wide Analysis Tool documentation.

For on-premises customers, you can also install the Site-Wide Analysis Tool using an agent to access the same experience as Cloud customers. Refer to our installation guide for more details.

In addition to running this tool to catch these issues, we also recommend visiting the the Adobe Commerce Support Knowledge Base.