Cloud site is slow

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


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.

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: " | 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.

Troubleshooting for overall cache hit rate

  1. Using the hourly and daily hit rate stats, identify when the hit rate started to decrease. If the hit rate suddenly dropped around the same time that you deployed a change to your site, consider rolling back the change until the site load comes down.
  2. Check the configuration in the Commerce Admin, under Stores > Configuration > Advanced > System > Full Page Cache. Make sure that TTL for public content value is not set too low.
  3. Make sure you’ve uploaded the VCL snippets.
  4. If you use custom VCL snippets, debug them for correct usage of the “pass” or “pipe” actions: they should be used carefully and at the very least used with a condition of some sort. For more tips, see Custom Fastly VCL snippets in our developer documentation.

Step 3: Identify the websites causing the high server load

You can use either of the following methods to get information about the IP addresses accessing your Adobe Commerce store.

  • Check the HTTP access logs through an SSH session.
  • Contact Adobe Commerce support to request a list of IP addresses causing heavy load on the site.

Check the HTTP access logs

To view your site’s access log, run the following command from your local development environment:

magento-cloud log access

View more lines with the


option, for example:

magento-cloud log access --lines=500

You can view this log and check to see if a large portion of requests are coming from a specific IP address. Another way is to use awk , sort and uniq to automatically count the most frequently occurring IP addresses in the log, like the following:

magento-cloud log access --lines 2000 | awk '{print $1}' | sort | uniq -c | sort

If the

magento-cloud log

command doesn’t work, you can connect to the remote server with SSH and check the log file at /var/log/access.log

After you identify the IP addresses that are causing heavy server load, you can block them by configuring an IP block list from in the Commerce Admin panel, under Stores > Configuration > ADVANCED > System > Full Page Cache > Fastly Configuration > Blocking.

If you cannot access your Admin due to heavy load, you can use the Fastly API to set up the blocking rules:

  1. Create the ACL as described in the Working with ACLs using the API Fastly doc.

  2. In the recv section, create a VCL snippet with the following content, having replaced ACL_NAME_GOES_HERE with the name of the ACL that was created in the previous step:

    code language-none
    if( req.http.Fastly-Client-IP ~ ACL_NAME_GOES_HERE ) {
    error 403 "Forbidden";

For more information on blocking IP addresses, see the Fastly Adobe Commerce module guide in GitHub.