Cloud site is slow

Last update: November 6, 2024

CREATED FOR:

  • Developer

This article provides recommendations on how to make your Adobe Commerce on cloud infrastructure site better performing under heavy traffic loads and how to cut this load.

Affected versions and editions

  • Adobe Commerce on cloud infrastructure, all versions

Issue

Steps to reproduce

  1. Visit your Adobe Commerce store.
  2. Browse a category page.
  3. Add a product to the cart.

Expected result

The site is responsive and adding a product to the cart is fast.

Actual result

The site is slow, or the category pages are fast but the cart page is slow.

Debugging steps and solutions

Take the following steps to track down the reason of the slow performance and fix it. You can switch the first and second steps, but proceed to blocking IPs only if the cache settings optimization does not help.

  1. Check the cache hit rate for the pages with high traffic and reduce the amount of heavily-updated data.
  2. Check the overall site cache hit rate and verify the general cache/Fastly configuration.
  3. Identify the web clients causing the high server load and block IP’s causing the high load.

The following paragraphs provide more details for each step.

Step 1: Check the cache hit rate for the pages with high traffic

The first step to fixing a site bogged down by heavy traffic is to ensure the pages with the heaviest traffic, like the store’s home page and the top-level category pages, are being cached properly.

You can find out the cache hit rates for these pages by reviewing the X-Cache HTTP headers using cURL, as described in Checking cache using cURL in the Fastly documentation. Or check the same headers using the network tab in the developer toolbar of your favorite web browser.

Fastly generally respects the response headers coming from the application; however, if the headers are all set to “do not cache” and for the page “to expire in the past,” Fastly cannot cache the page.

WARNING
Note that Fastly changes response headers, so checking the main URL with cURL or the web browser will not necessarily show which headers are being emitted by the application. It’s common for Fastly itself to respond to web browsers with “no cache” headers, but for the web application itself to allow caching and for Fastly to properly cache the item. So the “cache-control” and “pragma” headers information will not be useful in this case.

Troubleshooting for pages with high traffic

If the index page has a low hit rate, you can fix it by reducing the amount of heavily-updated data present on that page.

Step 2: Check the overall site cache hit rate

To check the overall cache hit rate:

  1. Get Fastly credentials for your Adobe Commerce on cloud infrastructure environment.

  2. Run the following Linux/macOS cURL command to check the hit rate for your site over the last 30 minutes, replacingand with the values for your Fastly credentials:

    curl -H "Fastly-Key: " https://api.fastly.com/stats/service//field/hit_ratio?by=minute | json_pp

    You can also check historical hit rates over the last day or month by changing the time range query option from ?by=minute to ?by=hour or ?by=day. For more information on getting Fastly cache stats, see Query Options in the Fastly documentation.

    The | json_pp option pretty prints the JSON response output using the json_pp utility. If you get a_‘json_pp not found’_ error, install the json_pp utility, or use another command line tool for JSON pretty printing. Alternatively, delete the | json_pp parameter and run the command again. The JSON response output is not formatted, but you can run it through a JSON beautifier to clean it up.

A hit rate above 0.90 or 90% indicates that the full-page cache is working.

A hit rate below 0.85 or 85% might indicate a site configuration problem, or you might have a third-party extension installed that does not allow its content to be cached.