[雲端上的Commerce]{class="badge informative" title="僅適用於雲端專案上的Adobe Commerce 。"}
Valkey和Redis服務組態的最佳作法
在雲端部署上為Adobe Commerce設定Redis或Valkey以供Adobe Commerce應用程式快取、工作階段儲存空間和L2快取使用時,請使用這些建議。
如需Adobe Commerce內部部署快取組態,請參閱效能最佳化的L2快取組態。
這些建議涵蓋下列內容:
- 選取支援的快取服務
- 啟用復本連線
- 個別的快取和工作階段執行個體
- 設定快取壓縮
- 啟用非同步釋放
- 啟用多執行緒I/O
- 增加使用者端逾時和重試次數
- 設定L2快取,包括預先載入金鑰、過時快取及Symfony L2快取
- 檢閱設定範例
選取支援的快取服務
Adobe Commerce 2.4.9的快取設定以及系統需求指定Valkey的修補程式發行版本不支援Redis。 請一律驗證快取後端選項和儲存體參考和系統需求中的確切Commerce版本、修補程式層級和服務版本。
啟用復本連線
啟用.magento.env.yaml檔案中的復本連線。 這項變更可讓Adobe Commerce使用額外的快取連線進行讀取,同時繼續使用主要端點進行寫入。 此設定可減少主要快取服務的讀取負載,並更有效地分配讀取流量。
ece-tools版本。 在依賴此設定之前,請執行echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp並檢查USE_SLAVE_CONNECTION專案,以確認您的服務存在復本關係。 若要確認您的拓朴是否布建復本端點,請升級ece-tools並重新部署,或者如果沒有USE_SLAVE_CONNECTION專案,請聯絡Adobe Commerce支援。symfony_l2,復本連線支援是透過ece-tools和雲端修補程式更新提供。 除了變更VALKEY_USE_SLAVE_CONNECTION: true之外,不需要額外的快取設定。 更新至最新的ece-tools版本以接收修正。對於Valkey,請使用:
| code language-yaml |
|---|
|
如需環境變陣列態詳細資訊,請參閱雲端基礎結構指南上的 Commerce 中的VALKEY_USE_SLAVE_CONNECTION。
對於Redis,請使用:
| code language-yaml |
|---|
|
如需環境變陣列態詳細資訊,請參閱雲端基礎結構指南上的 Commerce 中的REDIS_USE_SLAVE_CONNECTION。
個別的快取和工作階段執行個體
快取和工作階段設定是獨立的。 無論您使用哪個快取後端或L2快取實施,SESSION_CONFIGURATION都不會影響快取行為。 將快取與工作階段分開可讓您獨立管理它們。 它可減少快取與工作階段流量之間的爭用,防止快取相關壓力影響工作階段,並允許每個Redis或Valkey執行個體根據其本身的工作負載調整大小與調整。
.magento/services.yaml和.magento.app.yaml檔案,如下面的步驟3所述。若要布建工作階段的專用執行個體,請遵循下列步驟:
-
更新
.magento/services.yaml設定檔,將<version>取代為您正在使用的服務版本。 請參閱發行版本所支援的服務版本的系統需求。code language-yaml mysql: type: mysql:<version> disk: 35000 valkey: type: valkey:<version> valkey-session: # This is for the new Valkey instance type: valkey:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> 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-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
將連線埠號碼新增至
.magento.env.yaml設定檔。note important IMPORTANT 只有在 ece-tools無法從MAGENTO_CLOUD_RELATIONSHIPSValkey工作階段服務定義自動偵測到Valkey工作階段連線埠時,才設定此連線埠。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
-
更新
.magento/services.yaml設定檔,將<version>取代為您正在使用的服務版本。code language-yaml mysql: type: mysql:<version> disk: 35000 redis: type: redis:<version> redis-session: # This is for the new Redis instance type: redis:<version> search: type: elasticsearch:<version> disk: 5000 rabbitmq: type: rabbitmq:<version> 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-shell echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp -
將連線埠號碼新增至
.magento.env.yaml設定檔。note important IMPORTANT 只有在 ece-tools無法從MAGENTO_CLOUD_RELATIONSHIPSRedis工作階段服務定義中自動偵測到Redis工作階段連線埠時,才設定此連線埠。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
快取壓縮
如果您使用超過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,立即解除金鑰的連結,並非同步地釋放其記憶體。啟用多執行緒I/O
若要在Adobe Commerce雲端基礎結構上啟用Redis I/O執行緒,請提交Adobe Commerce支援票證,要求下列I/O執行緒組態。 此設定可從主要執行緒解除安裝通訊端讀取、寫入和命令剖析,藉此提高輸送量,但代價是需提高CPU使用量。 在載入下驗證並監視主機。
針對Redis:
| code language-text |
|---|
|
若為Valkey:
| code language-text |
|---|
|
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的更多回覆時間,減少短時間尖峰期間間歇性連線和讀取逾時錯誤。
設定L2快取
在.magento.env.yaml組態檔中設定VALKEY_BACKEND或REDIS_BACKEND部署變數,以設定L2快取。
雲端基礎結構上的Adobe Commerce提供兩種L2快取實作。
- 舊版實作使用
RemoteSynchronizedCache搭配Cm_Cache_Backend_File進行本機儲存 - 現代實作使用
symfony_l2,並遵循PSR-6規範,且效能更佳。 新式實作僅支援Valkey。
(如果支援Valkey)
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'VALKEY_BACKEND: 'symfony_l2'在支援Valkey的Commerce 2.4.8及舊版上,使用此設定:
| code language-yaml |
|---|
|
在Commerce 2.4.9和更新版本上,將下列設定與Symfony L2實作搭配使用:
| code language-yaml |
|---|
|
在支援Redis的2.4.8版和更早版本的Commerce上,使用:
| code language-yaml |
|---|
|
如需環境組態詳細資訊,請參閱 雲端基礎結構上的Commerce指南 中的REDIS_BACKEND。
移轉至Valkey與Symfony L2快取
如果您正在將雲端專案上現有的Adobe Commerce從RemoteSynchronizedCache (Redis或Valkey)移轉至symfony_l2,請在更新.magento.env.yaml前檢閱下列專案。
-
變更部署變數足以啟用
symfony_l2。 單獨設定VALKEY_BACKEND: symfony_l2會自動建置完整的L2快取組態。 您不需要手動重新建立您先前使用的RemoteSynchronizedCache組態的backend_options結構。 請參閱設定 Symfony 二級快取。 -
從您現有的設定中移除
preload_keys。 如果您的RemoteSynchronizedCache設定在CACHE_CONFIGURATION下包含preload_keys,請在移轉時將其移除。 如需詳細資訊,請參閱預先載入金鑰。 -
自動變更過時的快取行為。 在
symfony_l2底下,ece-tools會自動啟用一般快取型別(例如layout、block_html、full_page和translate)的過時快取,而不需要RemoteSynchronizedCache所需的手動前端組態。 如果您先前手動設定過時的快取,且想要保留您之前的確切行為,請在移轉前檢閱啟用過時的快取。 -
壓縮需要明確的旗標。 如果您透過
CACHE_CONFIGURATION自訂symfony_l2壓縮,僅設定compression_lib不會啟用壓縮 — 也必須設定compress_data。 請參閱快取壓縮。 -
Redis不是
symfony_l2支援的遠端後端。 移轉至Valkey,作為此變更的一部分。 請參閱設定Valkey服務。 -
工作階段設定不受此移轉影響。
SESSION_CONFIGURATION獨立於快取後端,在移至symfony_l2時不需要變更。 請參閱個別的快取與工作階段執行個體。
app/etc/env.php中手動設定symfony_l2。 透過.magento.env.yaml進行設定,以便ece-tools在部署期間套用並維護設定。 請參閱設定 Symfony 二級快取。預先載入索引鍵
如果您使用正確的位置(backend_options或remote_backend_options下),預先載入金鑰可套用至symfony_l2組態。 不過,Adobe不建議搭配symfony_l2使用預先載入金鑰。 symfony_l2預先載入實作一次擷取一個索引鍵,因此不會像對RemoteSynchronizedCache那樣減少往返次數,而且它可以增加Valkey上的負載,而不會影響效能。
預先載入功能可讓您提供常用索引鍵清單,Magento會在第一次存取請求期間,於單一管道中擷取這些索引鍵。 接著Magento會將擷取的值保留在PHP記憶體中以供該要求剩餘部分使用,如此可減少重複的Redis或Valkey來回,並可改善這些金鑰的要求啟動載入效能。
您可以透過監視Redis或Valkey上的作用中命令來識別常用金鑰:
預先載入金鑰是在.magento.env.yaml組態檔中設定。 此範例顯示支援RemoteSynchronizedCache的Adobe Commerce 2.4.8和更早版本的設定。
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'
若要列出索引鍵,請執行以下命令:
redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys
10秒後,按Ctrl+C。然後執行下列命令:
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50
此記錄會列出您可以預先載入的金鑰。 若要檢視索引鍵的內容,請執行以下命令:
redis-cli -p 6370 -n 1 hgetall "<key_name>"
啟用過時的快取
過時快取是L2快取功能,可讓Adobe Commerce從/dev/shm提供現有的本機快取值,而其他要求已經在重新產生相同的專案。 這可防止並行請求等候。 這減少了重新產生昂貴快取專案時快取串流和鎖爭用。
若是Adobe Commerce 2.4.9和更新版本,請在.magento.env.yaml檔案中設定VALKEY_BACKEND: symfony_l2:
stage:
deploy:
VALKEY_BACKEND: symfony_l2
ece-tools會自動產生default前端和stale_cache_enabled前端,並將下列快取型別對應到已啟用的前端: layout、block_html、reflection、config_integration、config_integration_api、full_page和translate。 這些型別不需要手動use_stale_cache或前端設定。 此自動對應本身就是啟用選擇性過時快取的範例。 只有特定快取型別會使用已啟用的前端,而非所有前端。 若要自訂對應至stale_cache_enabled的型別,或新增超出預設值的型別,請參閱自訂 Symfony L2快取組態。
full_page快取型別與雲端基礎結構專案上的Adobe Commerce無關,因為它們使用Fastly進行全頁快取。 因為這個原因,本區段的手動設定範例省略full_page,即使ece-tools將其包含在預設symfony_l2對應中。下列舊版組態適用於Adobe Commerce 2.4.8和更早版本,其中使用RemoteSynchronizedCache,且需要手動過時快取和前端組態。 這裡也適用相同選擇性(而非全域)建議。
舊版RemoteSynchronizedCache後端如何運作
透過RemoteSynchronizedCache,Magento會維護每個快取專案的兩個復本: /dev/shm中的本機復本,以及Redis或Valkey中的遠端復本。 當遠端副本無法使用且該金鑰已存在重新產生鎖定時,並行要求可以接收先前的本機值,而不是等到寫入新的值為止。
若要啟用2.4.8及舊版的過時快取,請在.magento.env.yaml檔案中進行設定。
stage:
deploy:
REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
use_stale_cache: true
default快取前端啟用過時的快取,這會將過時的快取行為套用至使用該前端的所有快取專案。 透過此設定,Magento核心快取型別可如預期運作。 不過,如果您的專案包含自訂程式碼或擴充功能,這些程式碼或擴充功能會透過一般\Magento\Framework\App\Cache API (例如$this->cache->save())寫入快取而沒有專用的快取前端,則這些專案也可以在重新產生期間提供過時的值。default前端停用過時的快取,並只針對選取的快取型別啟用它,如下所示。分別針對每種快取型別啟用過時快取(舊版)
您只能透過在.magento.env.yaml中定義專用快取前端並將選取的快取型別對應到它來啟用選取的快取型別的過時快取。 此手動方法適用於舊版RemoteSynchronizedCache後端;symfony_l2會自動執行此對應,如上所述。
若要正常運作,自訂前端必須定義為CACHE_CONFIGURATION.frontend下的完整前端。 僅為新前端名稱定義use_stale_cache: true是不夠的。
設定範例
對於2.4.8版和更舊版本的Redis,下列設定會為layout、reflection、config_integration、config_integration_api和translate快取型別啟用過時快取,而其他使用預設前端且停用過時快取的使用者:
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...
stale_cache_enabled,讓新的前端保持相同的行為。設定Symfony L2快取
Adobe Commerce 2.4.9和更新版本支援symfony_l2快取後端。 symfony_l2後端是Adobe Commerce用來管理L1和L2快取行為的快取實作。 它不會取代Redis或Valkey做為遠端快取服務。
.magento.env.yaml部署變數設定symfony_l2,讓ece-tools在部署期間套用並維護設定。 請勿在app/etc/env.php中手動設定symfony_l2,因為部署可能會覆寫手動env.php變更。 如果ece-tools未套用symfony_l2,Commerce可能會回覆為檔案式快取,這可能會增加磁碟I/O、增加多節點環境的檔案系統復寫負荷,並降低效能。若要針對Adobe Commerce 2.4.9使用symfony_l2快取,請完成下列步驟:
-
確定雲端專案使用
ece-tools封裝v2002.2.12或更新版本。 -
在
.magento.env.yaml檔案中設定部署變數:VALKEY_BACKEND=symfony_l2。code language-yaml stage: deploy: VALKEY_BACKEND: symfony_l2
將VALKEY_BACKEND部署變數設為symfony_l2會自動從您的Valkey服務連線詳細資料建置完整的L2快取設定,包括default和stale_cache_enabled前端,且已對映通用快取型別。 定義CACHE_CONFIGURATION是選擇性的,只有在您想要自訂特定的後端選項時才需要。
cleanup_percentage)等問題,來改善Symfony的L2快取效能和可靠性。 這樣可以減少磁碟I/O和後端負載,同時改善快取一致性。 請參閱_Adobe Commerce設定指南_中的增強型Symfony L2快取效能和可靠性。自訂Symfony L2快取設定
ece-tools會自動衍生default和stale_cache_enabled前端的Valkey連線詳細資料(server、port、database、serializer、compression_lib、persistent_id)。 若要自訂其他後端選項(例如本機快取目錄),請將CACHE_CONFIGURATION與_merge: true以及VALKEY_BACKEND: symfony_l2一起定義。 您在此處定義的值會覆寫對應的自動產生預設值;任何忽略的選項都會繼續使用ece-tools自動衍生的值。
stage:
deploy:
VALKEY_BACKEND: symfony_l2
CACHE_CONFIGURATION:
_merge: true
frontend:
default:
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1
stale_cache_enabled:
backend: symfony_l2
backend_options:
remote_backend: valkey
local_backend: file
local_backend_options:
cache_dir: /dev/shm/magento_l1_stale
use_stale_cache: true
symfony_l2的CACHE_CONFIGURATION時,如果您有意指向專案的Valkey服務以外的快取端點,則僅覆寫server或port。 ece-tools封裝會自動從您的Valkey服務關聯性衍生這些值。server,則連線至專案的Valkey服務時,其值必須是localhost。 提供不正確的server或port值會導致部署失敗,並出現快取連線錯誤。適用於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檔案中的設定程式碼:
若是Commerce 2.4.9和更新版本,請使用下列設定將清除臨界值設定為90%:
| code language-yaml |
|---|
|
若是Commerce 2.4.8和較舊版本,請使用下列設定將清除臨界值設定為90%:
| code language-yaml |
|---|
|
快取需求會因您的專案設定和自訂第三方程式碼而異。 設定L2快取記憶體的大小,讓快取運作時不會頻繁發生臨界值點選。
理想情況下,L2快取記憶體的使用量會穩定在臨界值以下,以避免頻繁的儲存清除。
您可以執行下列CLI命令並檢閱/dev/shm行,檢查叢集每個節點上的L2快取儲存記憶體使用量。
df -h /dev/shm
使用方式會因節點而異,但會收斂到類似的值。
設定範例
使用以下範例作為您的Redis或Valkey服務設定的起點。
套用所有最佳實務建議
針對VALKEY_BACKEND: symfony_l2,讓ece-tools產生default和stale_cache_enabled前端及其快取型別對應。 請勿在廣泛的default前端設定use_stale_cache。 下方的CACHE_CONFIGURATION區塊僅包含明確的後端選項覆寫。
| code language-yaml |
|---|
|
對Adobe Commerce 2.4.8和更早版本上的Redis使用下列設定:
| code language-yaml |
|---|
|
依快取型別區分過時快取
| code language-yaml |
|---|
|
| code language-yaml |
|---|
|