ACP2E-4908: Large catalogs cause excessive Redis or Valkey memory usage
The ACP2E-4908 patch fixes the issue where large catalogs could cause excessive memory use in Valkey (or Redis) because separate layout cache entries were created for each product in each store view. This patch is available when the Quality Patches Tool (QPT) 1.1.83 is installed. The patch ID is ACP2E-4908. Please note that this issue is scheduled to be fixed in Adobe Commerce 2.4.10.
Affected products and versions
The patch is created for Adobe Commerce version:
- Adobe Commerce (all deployment methods) 2.4.8-p4
Compatible with Adobe Commerce versions:
- Adobe Commerce (all deployment methods) >=2.4.8 <2.4.10
magento/quality-patches package to the latest version and check the compatibility on the Quality Patches Tool: Search for patches page. Use the patch ID as a search keyword to locate the patch.Issue
Large catalogs can cause excessive memory use in Redis or Valkey because separate layout cache entries are created for each product in each store view.
Steps to reproduce:
-
Configure Valkey (or Redis) as the default cache backend.
-
Edit
app/etc/env.phpand set the cache.frontend.default block to:code language-none 'default' => [ 'id_prefix' => '061_', 'backend_options' => [ 'server' => 'valkey', // your Valkey/Redis hostname 'port' => '6379', 'database' => '1', 'password' => '', 'compress_data' => '0', // key recipe — leaves XML uncompressed 'persistent' => 0, 'read_timeout' => 10, 'connect_retries' => 2, ], 'backend' => 'redis', ],Then
flush: bin/magento cache:flush. -
Generate the medium performance fixture:
code language-none bin/magento setup:performance:generate-fixtures \ setup/performance-toolkit/profiles/ce/medium.xmlThis produces 3 websites × 3 store groups × 3 store views, 24K simple + 640 configurable products, 33 attribute sets, 50K orders. Expect 10 min on a fast machine.
-
Reset Valkey
db1and warm up:code language-none valkey-cli -h <host> -n 1 FLUSHDB bin/magento cache:flush -
Crawl product pages across stores. Build a sample list and hit each URL:
code language-none # Build 200 random product URLs across stores 1–4 mysql -e "SELECT CONCAT(s.code,'|',u.request_path) FROM url_rewrite u JOIN store s ON u.store_id=s.store_id WHERE u.entity_type='product' AND u.request_path NOT LIKE 'catalog/product/%' AND s.store_id BETWEEN 1 AND 4 ORDER BY RAND() LIMIT 200;" magento > urls.txt while IFS='|' read -r STORE URL; do curl -s -o /dev/null "http://<base-url>/${URL}?___store=${STORE}" done < urls.txt -
Observe the
LAYOUTcache footprint:code language-none valkey-cli -h <host> -n 1 --scan --pattern "*LAYOUT_FRONTEND_STORE*" | wc -l valkey-cli -h <host> INFO memory | grep used_memory_humanScale up the crawl (or use
large.xml/extra_large.xmland a real load tool like siege/wrk) to reach the customer’s 10K-keys / 1.7 GB regime.
Expected results:
Performance is not impacted when compression is enabled.
Actual results:
- The
LAYOUT_FRONTEND_STORERedis keys consume a significant amount of space. - On a fresh medium-fixture install, after 200 product hits: approximately 564
LAYOUT_FRONTEND_STOREkeys, andused_memory_humanof approximately 20 MB (vs. approximately 10 MB baseline before the crawl) — approximately 2.8 LAYOUT cache keys per product page hit, growing linearly with unique products visited × stores.
Apply the patch
To apply individual patches, use the following links depending on your deployment method:
- Adobe Commerce or Magento Open Source on-premises: Quality Patches Tool > Usage in the Quality Patches Tool guide
- Adobe Commerce on cloud infrastructure: Upgrades and Patches > Apply Patches in the Commerce on Cloud Infrastructure guide
Related reading
To learn more about Quality Patches Tool, refer to:
- Quality Patches Tool: A self-service tool for quality patches in the Tools guide