ACP2E-4908: cataloghi di grandi dimensioni causano un eccessivo utilizzo di memoria Redis o Valkey

Ultimo aggiornamento: 3 novembre 2026

Creato per:

Experienced
Amministratore
Sviluppatore

La patch ACP2E-4908 risolve il problema che i cataloghi di grandi dimensioni potrebbero causare un uso eccessivo della memoria in Valkey (o Redis) perché sono state create voci separate della cache di layout per ogni prodotto in ogni visualizzazione dello store. Questa patch è disponibile quando è installato Quality Patches Tool (QPT) 1.1.83. L’ID della patch è ACP2E-4908. Tieni presente che questo problema è pianificato per essere risolto in Adobe Commerce 2.4.10.

Prodotti e versioni interessati

La patch è stata creata per la versione di Adobe Commerce:

Adobe Commerce (tutti i metodi di implementazione) 2.4.8-p4

Compatibile con le versioni di Adobe Commerce:

Adobe Commerce (tutti i metodi di implementazione) >=2.4.8 <2.4.10

NOTE

La patch potrebbe diventare applicabile ad altre versioni con le nuove versioni di Quality Patches Tool. Per verificare se la patch è compatibile con la versione di Adobe Commerce in uso, aggiornare il pacchetto magento/quality-patches alla versione più recente e verificare la compatibilità nella pagina Quality Patches Tool: Cerca patch. Utilizza l’ID patch come parola chiave di ricerca per individuare la patch.

Problema

I cataloghi di grandi dimensioni possono causare un utilizzo eccessivo della memoria in Redis o Valkey perché vengono create voci separate della cache di layout per ogni prodotto in ogni visualizzazione dello store.

Passaggi da riprodurre:

Configurare Valkey (o Redis) come back-end della cache predefinito.

Modificare app/etc/env.php e impostare il blocco cache.frontend.default su:

code language-none

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', ],`

'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',
],

Quindi flush: bin/magento cache:flush.

Generare lo staffaggio con prestazioni medie:

code language-none
`bin/magento setup:performance:generate-fixtures \ setup/performance-toolkit/profiles/ce/medium.xml`

Questo produce 3 siti web × 3 gruppi di store × 3 visualizzazioni di store, 24K di prodotti semplici + 640 configurabili, 33 set di attributi, 50K ordini. 10 minuti in una macchina veloce.

Reimposta Valkey db1 e riscalda:

code language-none
`valkey-cli -h <host> -n 1 FLUSHDB bin/magento cache:flush`

Scansiona pagine di prodotti tra i vari negozi. Crea un elenco di esempio e premi ogni URL:

code language-none

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`

# 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

Osservare l’ingombro della cache LAYOUT:

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_human`

Aumentare il scansiono (oppure utilizzare large.xml/extra_large.xml e uno strumento di carico reale come siege/wrk) per raggiungere il regime di 10.000 chiavi/1,7 GB del cliente.

Risultati previsti:

Le prestazioni non sono influenzate quando la compressione è abilitata.

Risultati effettivi:

Le chiavi LAYOUT_FRONTEND_STORE Redis occupano molto spazio.
In una nuova installazione di medie dimensioni, dopo 200 hit di prodotto: circa 564 chiavi LAYOUT_FRONTEND_STORE e used_memory_human di circa 20 MB (rispetto a circa 10 MB di base prima del scansiono): circa 2,8 chiavi della cache LAYOUT per hit pagina di prodotto, in crescita lineare con prodotti univoci visitati × store.

Applicare la patch

Per applicare singole patch, utilizzare i collegamenti seguenti, a seconda del metodo di distribuzione utilizzato:

Adobe Commerce o Magento Open Source on-premise: Quality Patches Tool > Utilizzo nella guida di Quality Patches Tool
Adobe Commerce su infrastruttura cloud: Aggiornamenti e patch > Applica patch nella guida Commerce su infrastruttura cloud

Lettura correlata

Per ulteriori informazioni su Quality Patches Tool, vedere:

Quality Patches Tool: strumento self-service per patch di qualità nella guida degli strumenti

recommendation-more-help

commerce-operations-help-tools