[僅限PaaS]{class="badge informative" title="僅適用於雲端專案(Adobe管理的PaaS基礎結構)和內部部署專案的Adobe Commerce 。"}
Redis和Valkey服務組態的最佳作法
Last update: Mon Apr 06 2026 00:00:00 GMT+0000 (Coordinated Universal Time)
使用這些建議為Adobe Commerce快取和工作階段設定Redis或Valkey。
- 設定L2快取
- 啟用從屬連線
- 預先載入索引鍵
- 啟用過時的快取
- 分隔快取和工作階段
- 壓縮快取
- 設定範例
針對雲端基礎結構環境上的Commerce,請確認您使用的是最新版本的
ece-tools套件。 如果沒有,
升級至最新版本。 您可以使用
composer show magento/ece-tools CLI命令檢查本機環境中安裝的版本。
設定L2快取
在REDIS_BACKEND組態檔中設定VALKEY_BACKEND或.magento.env.yaml部署變數,以設定L2快取。
Redis組態
對於Redis,請使用:
| code language-yaml |
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
|
如需雲端基礎結構上的環境設定,請參閱REDIS_BACKEND雲端基礎結構上的Commerce指南中的__設定參考。
若為內部部署安裝,請參閱設定指南中的設定Redis頁面快取。
Valkey組態
對於Valkey,請使用:
| code language-yaml |
stage:
deploy:
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
|
如需雲端基礎結構上的環境設定,請參閱VALKEY_BACKEND雲端基礎結構上的Commerce指南中的__設定參考。
如需內部部署安裝,請參閱設定指南中的設定Valkey。
適用於Adobe Commerce Cloud的L2快取記憶體大小
L2快取使用暫存檔案系統 (/dev/shm)作為其儲存機制。 與專門化的機碼值存放區不同,tmpfs沒有機碼收回原則,因此記憶體使用量可能會無限增加。 為避免耗盡,當使用量達到可設定的臨界值(預設為95%)時,Adobe Commerce會自動清除L2儲存空間。 您可以要求較大的/dev/shm掛載或降低清除臨界值,以控制記憶體耗用量。
根據您的專案需求,調整L2快取記憶體使用量上限。 使用下列其中一種方法:
- 建立支援票證以調整
/dev/shm掛載大小。 針對此案例,Adobe建議將/dev/shm掛載大小設定為15 GB。
- 在應用程式層級調整
cleanup_percentage屬性,以限制儲存使用量,並釋放其他服務可用的記憶體。
您可以在快取組態群組cache/frontend/default/backend_options/cleanup_percentage下的部署組態中調整組態。
cleanup_percentage可設定的選項已在Adobe Commerce 2.4.4中匯入。
下列範例顯示.magento.env.yaml檔案中的設定程式碼:
Redis組態
| code language-yaml |
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
cleanup_percentage: 90
|
Valkey組態
| code language-yaml |
stage:
deploy:
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
cleanup_percentage: 90
|
快取需求會因您的專案設定和自訂第三方程式碼而異。 設定L2快取記憶體的大小,讓快取運作時不會頻繁發生臨界值點選。
理想情況下,L2快取記憶體的使用量會穩定在臨界值以下,以避免頻繁的儲存清除。
您可以執行下列CLI命令並檢閱/dev/shm行,檢查叢集每個節點上的L2快取儲存記憶體使用量。
使用方式會因節點而異,但應該會收斂到類似的值。
設定L2快取的自訂目錄
最佳化L2快取效能時,您可以選擇將本機快取檔案儲存在自訂的高效能目錄中,例如RAM磁碟(/dev/shm/)。
若要確保應用程式範圍的一致性並防止零碎的快取儲存,請在app/etc/env.php檔案中設定特定的L2後端選項和全域目錄登入。
最佳實務:同時定義local_backend_options['cache_dir']和全域directories['cache']['path']。
local_backend_options['cache_dir']:指示後端快取配接器(例如Cm_Cache_Backend_File)將其同步的L2快取檔案儲存在指定的位置。
directories['cache']['path']:更新Adobe Commerce DirectoryList登入,將自訂路徑建立為整個應用程式的最終系統快取目錄。
防止分割快取目錄和GlusterFS分段錯誤
如果您只在local_backend_options中定義自訂路徑,則L2快取引擎會正確運作,但全域應用程式登入仍會將var/cache識別為預設快取位置。
此組態不符會導致「腦分割」的情況,即協力廠商擴充功能或核心遞補處理作業將暫存檔案寫入預設的var/cache目錄。
對Adobe Commerce Cloud的嚴重影響:在Pro架構上,var/目錄掛載在共用的分散式檔案系統上。 透過此網路掛載強制高速快取I/O會壓垮使用者端,而且是GlusterFS分段錯誤和整個叢集中斷的主要觸發條件。 設定這兩個設定可確保所有的快取I/O都嚴格保留在本機高效能磁碟上。
設定範例
若要強制執行單一、統一的快取目錄,請更新您的env.php檔案以包含兩個設定:
return [
// 1. Override the global directory registry
'directories' => [
'cache' => [
'path' => '/dev/shm/magento_cache'
]
],
// 2. Configure the L2 cache engine
'cache' => [
'frontend' => [
'default' => [
'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
'backend_options' => [
'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
'server' => '127.0.0.1',
'port' => '6379',
'database' => '1',
// ... other redis configurations ...
'local_backend' => 'Cm_Cache_Backend_File',
'local_backend_options' => [
'cache_dir' => '/dev/shm/magento_cache'
]
]
]
]
],
// ...
];
啟用從屬連線
啟用.magento.env.yaml檔案中的從屬連線,讓Adobe Commerce使用額外的唯讀快取連線進行讀取,同時繼續使用主要端點進行寫入。 此設定可減少主要快取服務的讀取負載,並更有效地分配讀取流量。
Redis組態
對於Redis,請使用:
| code language-yaml |
stage:
deploy:
REDIS_USE_SLAVE_CONNECTION: true
|
如需Commerce Cloud基礎結構的環境設定,請參閱雲端基礎結構指南上的Commerce中的REDIS_USE_SLAVE_CONNECTION。
針對Adobe Commerce內部部署安裝,請使用bin/magento setup命令設定新的Redis快取實作。 請參閱組態指南中的 使用預設快取 的Redis。
Valkey組態
對於Valkey,請使用:
| code language-yaml |
stage:
deploy:
VALKEY_USE_SLAVE_CONNECTION: true
|
如需Commerce Cloud基礎結構的環境設定,請參閱雲端基礎結構指南上的Commerce中的VALKEY_USE_SLAVE_CONNECTION。
針對Adobe Commerce內部部署安裝,請使用bin/magento setup命令設定新的Valkey快取實作。 請參閱設定指南中的設定Valkey。
預先載入索引鍵
Magento通常會一次從Redis或Valkey載入一個索引鍵中的快取專案。 預先載入功能可讓您提供常用索引鍵清單,Magento會在第一次存取請求期間,於單一管道中擷取這些索引鍵。 接著Magento會將擷取的值保留在PHP記憶體中以供該要求剩餘部分使用,如此可減少重複的Redis或Valkey來回,並可改善這些金鑰的要求啟動載入效能。
您可以透過監視Redis或Valkey上的作用中命令來識別常用金鑰:
Redis預先載入金鑰組態
預先載入金鑰是在.magento.env.yaml組態檔中設定。
| code language-yaml |
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
backend_options:
preload_keys: # List the keys to be preloaded
- '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
- '061_GLOBAL_PLUGIN_LIST:hash'
- '061_DB_IS_UP_TO_DATE:hash'
- '061_SYSTEM_DEFAULT:hash'
|
若要列出索引鍵,請執行以下命令:
| code language-terminal |
redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys
|
10秒後,按Ctrl+C。 然後執行下列命令:
| code language-terminal |
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50
|
此記錄會列出您可以預先載入的金鑰。 若要檢視索引鍵的內容,請執行以下命令:
| code language-terminal |
redis-cli -p 6370 -n 1 hgetall "<key_name>"
|
如需內部部署安裝,請參閱設定指南中的Redis預先載入功能。
Valkey預先載入金鑰組態
預先載入金鑰是在.magento.env.yaml組態檔中設定。
| code language-yaml |
stage:
deploy:
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
backend_options:
preload_keys: # List the keys to be preloaded
- '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
- '061_GLOBAL_PLUGIN_LIST:hash'
- '061_DB_IS_UP_TO_DATE:hash'
- '061_SYSTEM_DEFAULT:hash'
|
若要列出索引鍵,請執行以下命令:
| code language-terminal |
valkey-cli -p 6370 -n 1 MONITOR > /tmp/list.keys
|
10秒後,按Ctrl+C。 然後執行下列命令:
| code language-terminal |
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50
|
此記錄會列出您可以預先載入的金鑰。 若要檢視索引鍵的內容,請執行以下命令:
| code language-terminal |
valkey-cli -p 6370 -n 1 hgetall "<key_name>"
|
如需內部部署安裝,請參閱設定指南中的Valkey預先載入功能。
啟用過時的快取
過時快取是RemoteSynchronizedCache的L2快取功能。 啟用後,Adobe Commerce可在另一個要求已重新產生相同專案時,從/dev/shm提供現有的本機快取值,而非讓每個並行要求等待。 這減少了重新產生昂貴快取專案時快取串流和鎖爭用。
運作方式
透過RemoteSynchronizedCache,Magento會維護每個快取專案的兩個復本: /dev/shm中的本機復本,以及Redis或Valkey中的遠端復本。 當遠端副本無法使用且該金鑰已存在重新產生鎖定時,並行要求可以接收先前的本機值,而不是等到寫入新的值為止。
若要啟用過時的快取,請在.magento.env.yaml檔案中進行設定。
設定Redis的過時快取
針對Redis:
| code language-yaml |
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
use_stale_cache: true
|
設定Valkey的過時快取
若為Valkey:
| code language-yaml |
stage:
deploy:
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
use_stale_cache: true
|
full_page快取型別與雲端基礎結構專案上的Adobe Commerce無關,因為它們使用
Fastly。
如需內部部署安裝,請參閱設定指南中的過時快取選項。
上述設定會在default快取前端啟用過時的快取,這會將過時的快取行為套用至使用該前端的所有快取專案。 使用此設定時,Magento核心快取型別通常會如預期般運作。 不過,如果您的專案包含自訂程式碼或擴充功能,這些程式碼或擴充功能會透過一般\Magento\Framework\App\Cache API (例如$this->cache->save())寫入快取而沒有專用的快取前端,則這些專案也可以在重新產生期間提供過時的值。
如果這會在您的自訂內容中造成非預期的行為,請在
default前端停用過時快取,並只對選取的快取型別啟用它,如通常的
內部部署一樣。
分別啟用每個快取型別的過時快取
您只能透過在.magento.env.yaml中定義專用快取前端並將選取的快取型別對應到它來啟用選取的快取型別的過時快取。
若要正常運作,自訂前端必須定義為CACHE_CONFIGURATION.frontend下的完整前端。 僅為新前端名稱定義use_stale_cache: true是不夠的。
設定範例
設定Redis的過時快取
針對Redis:
| code language-yaml |
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # In this frontend, we keep stale cache set to false.
id_prefix: '001_'
backend_options:
use_stale_cache: false
# Now, create a new frontend called 'stale_cache_enabled'.
# It must contain the same backend connection settings as the frontend 'default':
stale_cache_enabled:
id_prefix: '001_'
backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
backend_options:
remote_backend: '\Magento\Framework\Cache\Backend\Redis'
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the frontend 'default' in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same port used by the frontend 'default' in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: 'Cm_Cache_Backend_File'
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true # stale cache here is enabled
# Now select which cache types you want to enable (stale_cache_enabled), or disable (default)
type:
default:
frontend: default
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
|
設定Valkey的過時快取
若為Valkey:
| code language-yaml |
stage:
deploy:
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # In this frontend, we keep stale cache set to false.
id_prefix: '001_'
backend_options:
use_stale_cache: false
# Now, create a new frontend called 'stale_cache_enabled'.
# It must contain the same backend connection settings as the frontend 'default':
stale_cache_enabled:
id_prefix: '001_'
backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
backend_options:
remote_backend: '\Magento\Framework\Cache\Backend\Redis'
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the frontend 'default' in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same port used by the frontend 'default' in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: 'Cm_Cache_Backend_File'
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true # stale cache here is enabled
# Now select which cache types you want to enable (stale_cache_enabled), or disable (default)
type:
default:
frontend: default
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
|
如果來源前端設定了其他後端選項,例如壓縮、重試、預先載入金鑰或其他調整值,請將這些選項複製到stale_cache_enabled,以便新的前端保持相同的行為。
個別的快取和工作階段執行個體
將快取與工作階段分開可讓您獨立管理它們。 它可減少快取與工作階段流量之間的爭用,防止快取相關壓力影響工作階段,並允許每個Redis或Valkey執行個體根據其本身的工作負載調整大小與調整。
請依照下列步驟,為工作階段布建專用執行個體:
Redis
-
更新.magento/services.yaml設定檔。
| code language-yaml |
mysql:
type: mysql:10.4
disk: 35000
redis:
type: redis:6.0
redis-session: # This is for the new Redis instance
type: redis:6.0
search:
type: elasticsearch:7.9
disk: 5000
rabbitmq:
type: rabbitmq:3.8
disk: 2048
|
-
更新.magento.app.yaml設定檔。
| code language-yaml |
relationships:
database: "mysql:mysql"
redis: "redis:redis"
redis-session: "redis-session:redis" # Relationship of the new Redis instance
search: "search:elasticsearch"
rabbitmq: "rabbitmq:rabbitmq"
|
-
請求專用於生產和中繼環境工作階段的新Redis執行個體。
提交Adobe Commerce支援票證。 包含更新的.magento/services.yaml與.magento.app.yaml組態檔。
此更新不會造成任何停機時間,但需要部署才能啟用新服務。
-
確認新執行個體正在執行,並記下連線埠號碼。
| code language-bash |
echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp
|
-
將連線埠號碼新增至.magento.env.yaml設定檔。
| note important |
| IMPORTANT |
只有在ece-tools無法從MAGENTO_CLOUD_RELATIONSHIPS Redis工作階段服務定義中自動偵測到Redis工作階段連線埠時,才設定此連線埠。 |
| note note |
| NOTE |
將disable_locking設定為1以獲得最佳效能。 在極少數情況下,由於高並行工作階段活動而導致競爭情況,請將其設定為0以啟用鎖定。 |
| code language-yaml |
SESSION_CONFIGURATION:
_merge: true
redis:
timeout: 5
disable_locking: 1
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
-
從Redis快取執行個體上的預設資料庫 (db 0)移除工作階段。
| code language-terminal |
redis-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
|
Valkey
-
更新.magento/services.yaml設定檔。
| code language-yaml |
mysql:
type: mysql:10.4
disk: 35000
valkey:
type: valkey:8.0
valkey-session: # This is for the new Valkey instance
type: valkey:8.0
search:
type: elasticsearch:7.9
disk: 5000
rabbitmq:
type: rabbitmq:3.8
disk: 2048
|
-
更新.magento.app.yaml設定檔。
| code language-yaml |
relationships:
database: "mysql:mysql"
valkey: "valkey:valkey"
valkey-session: "valkey-session:valkey" # Relationship of the new Valkey instance
search: "search:elasticsearch"
rabbitmq: "rabbitmq:rabbitmq"
|
-
請求專用於生產和中繼環境工作階段的新Valkey執行個體。
提交Adobe Commerce支援票證。 包含更新的.magento/services.yaml與.magento.app.yaml組態檔。
此更新不會造成任何停機時間,但需要部署才能啟用新服務。
-
確認新執行個體正在執行,並記下連線埠號碼。
| code language-bash |
echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp
|
-
將連線埠號碼新增至.magento.env.yaml設定檔。
| note important |
| IMPORTANT |
只有在ece-tools無法從MAGENTO_CLOUD_RELATIONSHIPS Valkey工作階段服務定義自動偵測到Valkey工作階段連線埠時,才設定此連線埠。 |
| note note |
| NOTE |
將disable_locking設定為1以獲得最佳效能。 在極少數情況下,由於高並行工作階段活動而導致競爭情況,請將其設定為0以啟用鎖定。 |
| code language-yaml |
SESSION_CONFIGURATION:
_merge: true
redis: # keep 'redis' even if you are using Valkey.
timeout: 5
disable_locking: 1
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
-
從Valkey快取執行個體上的預設資料庫 (db 0)移除工作階段。
| code language-terminal |
valkey-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
|
快取壓縮
如果您使用超過6 GB的Redis或Valkey maxmemory,則可以啟用快取壓縮來減少金鑰所消耗的空間。 請注意,此設定可交換使用者端效能以節省記憶體。 如果您有備用CPU容量,請考慮啟用它。 請參閱組態指南中的使用工作階段存放區的Redis或使用工作階段存放區的Valkey。
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
compress_data: 4 # 0-9
compress_tags: 4 # 0-9
compress_threshold: 20480 # don't compress files smaller than this value
compression_lib: 'gzip' # snappy and lzf for performance, gzip for high compression (~69%)
啟用非同步釋放
若要在雲端基礎結構上的Adobe Commerce上啟用lazyfree,請提交Adobe Commerce支援票證,要求將下列Redis或Valkey設定套用至您的環境:
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes
啟用lazyfree時,Redis或Valkey會將記憶體回收解除安裝到背景執行緒,以進行逐出、過期、伺服器啟動的刪除、使用者刪除和復本資料集清除。 這減少了主執行緒封鎖,並可減少請求延遲。
lazyfree-lazy-user-del yes選項會使DEL命令的行為類似UNLINK,立即解除金鑰的連結,並非同步地釋放其記憶體。
由於釋放發生在背景,由已刪除、已過期或收回的金鑰使用的記憶體仍會保持配置,直到背景執行緒完成工作為止。 如果您的Redis或Valkey執行個體已處於記憶體緊張的壓力下,請謹慎測試並考慮先降低記憶體壓力。 例如,針對特定案例停用區塊快取,並依照上述說明分別停用快取和工作階段Redis例項。
啟用多執行緒I/O
若要在雲端基礎結構上的Adobe Commerce上啟用Redis I/O執行緒,請提交請求下列I/O執行緒設定的Adobe Commerce支援票證。 此設定可從主執行緒解除安裝通訊端讀取和寫入以及命令剖析,藉此提高輸送量,但代價是需提高CPU使用量。 在載入下驗證並監視主機。
設定Redis的I/O執行緒
針對Redis:
| code language-text |
io-threads-do-reads yes
io-threads 8 # Choose a value lower than the number of CPU cores (check with nproc), and then tune under load.
|
設定Valkey的I/O執行緒
若為Valkey:
| code language-text |
io-threads-do-reads yes
io-threads 8 # choose a value lower than the number of CPU cores (check with nproc), then tune under load
events-per-io-thread 2
|
I/O執行緒只會平行處理使用者端I/O和剖析。 Redis指令執行仍維持單一執行緒。
啟用I/O執行緒可能會增加CPU的使用量,而且不會使每個工作負荷都受益。 從保守的值和基準開始。 如果延遲增加或CPU飽和,請減少io-threads或停用I/O執行緒中的讀取。
增加使用者端逾時和重試次數
調整.magento.env.yaml中的後端選項,將Redis或Valkey快取使用者端的容許度增加到短期飽和度。
stage:
deploy:
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
connect_retries: 3 # Number of connection retries
remote_backend_options:
read_timeout: 10 # Timeout
這些設定可藉由重試連線設定並允許Redis或Valkey的更多回覆時間,減少短時間尖峰期間間歇性連線和讀取逾時錯誤。
這些設定有助於緩解短暫的擁塞,但無法修正持續性的超載。
設定範例
使用以下範例作為您的Redis或Valkey服務設定的起點。
套用所有最佳實務建議
Redis
| code language-yaml |
stage:
deploy:
MYSQL_USE_SLAVE_CONNECTION: true
REDIS_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '001_' # Any prefix is fine, but keep it consistent.
backend_options:
use_stale_cache: true # Enables stale cache feature for all cache types
connect_retries: 3 # Number of connection retries
preload_keys: # Preload keys at backend_options level (official Adobe placement)
- '001_EAV_ENTITY_TYPES:hash' # Bootstrap: entity types
- '001_GLOBAL_PLUGIN_LIST:hash' # Bootstrap: DI plugin list
- '001_DB_IS_UP_TO_DATE:hash' # Bootstrap: schema version
- '001_SYSTEM_DEFAULT:hash' # Config: system defaults
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
remote_backend_options:
read_timeout: 10
retry_reads_on_master: 1 # Required for split architecture
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4 # 0-9
# compress_tags: 4 # 0-9
# compress_threshold: 20480 # don't compress files smaller than this value
# compression_lib: 'gzip' # snappy and lzf for performance, gzip for high compression (~69%)
SESSION_CONFIGURATION:
_merge: true
redis:
# port: 6372 # ece-tools should detect the port automatically, but if not, set here.
timeout: 5
disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
Valkey設定範例
| code language-yaml |
stage:
deploy:
MYSQL_USE_SLAVE_CONNECTION: true
VALKEY_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
VALKEY_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
id_prefix: '001_' # any prefix is fine, but keep it consistent.
backend_options:
use_stale_cache: true # Enables stale cache feature for all cache types
connect_retries: 3 # Number of connection retries
preload_keys: # Preload keys at backend_options level (official Adobe placement)
- '001_EAV_ENTITY_TYPES:hash' # Bootstrap: entity types
- '001_GLOBAL_PLUGIN_LIST:hash' # Bootstrap: DI plugin list
- '001_DB_IS_UP_TO_DATE:hash' # Bootstrap: schema version
- '001_SYSTEM_DEFAULT:hash' # Config: system defaults
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
remote_backend_options:
read_timeout: 10
retry_reads_on_master: 1 # Required for split architecture
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4 # 0-9
# compress_tags: 4 # 0-9
# compress_threshold: 20480 # don't compress files smaller than this value
# compression_lib: 'gzip' # snappy and lzf for performance, gzip for high compression (~69%)
SESSION_CONFIGURATION:
_merge: true
redis:
# port: 6372 # ece-tools should detect the port automatically, but if not, set here.
timeout: 5
disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
套用所有最佳實務建議,並依快取型別區分過時快取
Redis
| code language-yaml |
stage:
deploy:
MYSQL_USE_SLAVE_CONNECTION: true
REDIS_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # Keep stale cache disabled on the broad default frontend.
id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
backend_options:
use_stale_cache: false # stale cache false here
connect_retries: 3
preload_keys:
- '001_EAV_ENTITY_TYPES:hash'
- '001_GLOBAL_PLUGIN_LIST:hash'
- '001_DB_IS_UP_TO_DATE:hash'
- '001_SYSTEM_DEFAULT:hash'
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
remote_backend_options:
read_timeout: 10
retry_reads_on_master: 1
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4
# compress_tags: 4
# compress_threshold: 20480
# compression_lib: 'gzip'
stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
backend: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
backend_options:
remote_backend: \Magento\Framework\Cache\Backend\Redis
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the source frontend in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same slave connection/read port used by the source frontend in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: Cm_Cache_Backend_File
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true
connect_retries: 3
preload_keys:
- '001_EAV_ENTITY_TYPES:hash'
- '001_GLOBAL_PLUGIN_LIST:hash'
- '001_DB_IS_UP_TO_DATE:hash'
- '001_SYSTEM_DEFAULT:hash'
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4
# compress_tags: 4
# compress_threshold: 20480
# compression_lib: 'gzip'
type:
default:
frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
block_html:
frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
SESSION_CONFIGURATION:
_merge: true
redis:
# port: 6372 # ece-tools should detect the port automatically, but if not, set here.
timeout: 5
disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
Valkey
| code language-yaml |
stage:
deploy:
MYSQL_USE_SLAVE_CONNECTION: true
VALKEY_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
VALKEY_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
CACHE_CONFIGURATION:
_merge: true
frontend:
default: # Keep stale cache disabled on the broad default frontend.
id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
backend_options:
use_stale_cache: false # stale cache false here
connect_retries: 3
preload_keys:
- '001_EAV_ENTITY_TYPES:hash'
- '001_GLOBAL_PLUGIN_LIST:hash'
- '001_DB_IS_UP_TO_DATE:hash'
- '001_SYSTEM_DEFAULT:hash'
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
remote_backend_options:
read_timeout: 10
retry_reads_on_master: 1
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4
# compress_tags: 4
# compress_threshold: 20480
# compression_lib: 'gzip'
stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
backend: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
backend_options:
remote_backend: \Magento\Framework\Cache\Backend\Redis
remote_backend_options:
server: localhost
port: 6370 # Use the same port used by the source frontend in env.php
database: 1
load_from_slave:
server: localhost
port: 26370 # Use the same slave connection/read port used by the source frontend in env.php
retry_reads_on_master: 1
read_timeout: 10
local_backend: Cm_Cache_Backend_File
local_backend_options:
cache_dir: /dev/shm/
use_stale_cache: true
connect_retries: 3
preload_keys:
- '001_EAV_ENTITY_TYPES:hash'
- '001_GLOBAL_PLUGIN_LIST:hash'
- '001_DB_IS_UP_TO_DATE:hash'
- '001_SYSTEM_DEFAULT:hash'
- '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
# Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
# compress_data: 4
# compress_tags: 4
# compress_threshold: 20480
# compression_lib: 'gzip'
type:
default:
frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
block_html:
frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
layout:
frontend: stale_cache_enabled
reflection:
frontend: stale_cache_enabled
config_integration:
frontend: stale_cache_enabled
config_integration_api:
frontend: stale_cache_enabled
translate:
frontend: stale_cache_enabled
# add other cache types as needed...
SESSION_CONFIGURATION:
_merge: true
redis: # keep 'redis' even if you are using Valkey.
# port: 6372 # ece-tools should detect the port automatically, but if not, set here.
timeout: 5
disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
bot_first_lifetime: 60
bot_lifetime: 7200
max_lifetime: 2592000
min_lifetime: 60
|
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60