From 3f7916fc60ee43c0ecc81a699e90f6ea9d7db581 Mon Sep 17 00:00:00 2001 From: EclipseEternal <18310675+EclipseEternal@users.noreply.github.com> Date: Thu, 20 Aug 2026 11:49:32 +0100 Subject: [PATCH] Clarify L2 cache vs. cache preload: payload size vs. call count The L2 cache section described L2 caching as reducing "network traffic" without distinguishing that from reducing the number of remote cache calls. L2 caching still checks the remote cache on every read to validate its local copy - what shrinks is the payload of each call (a hash instead of the full value), not the number of round trips. The cache preload paragraph already pointed at the preload feature but described its benefit only as "decreases the pressure on Redis," without stating that it is an independent mechanism (usable with or without L2) and that it is specifically the round-trip-count reducer, via pipelining a fixed list of IDs into one batch. --- help/configuration/cache/level-two-cache.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/help/configuration/cache/level-two-cache.md b/help/configuration/cache/level-two-cache.md index adf36652f..740ffab7e 100644 --- a/help/configuration/cache/level-two-cache.md +++ b/help/configuration/cache/level-two-cache.md @@ -33,7 +33,7 @@ topic_v2: --- # L2 cache configuration for performance optimization -L2 (two-level) caching reduces network traffic between the remote cache storage (Redis or Valkey) and the Commerce application by adding a local cache layer on each web node. A standard Commerce instance transfers around 300 KB per request, and traffic can quickly grow to over 1000 requests in some situations. +L2 (two-level) caching reduces the amount of data transferred between the remote cache storage (Redis or Valkey) and the Commerce application by adding a local cache layer on each web node. Each web node still checks the remote cache on every read to validate its local copy, so L2 caching does not reduce the number of remote cache calls; it reduces the size of each call, since only a short hash is exchanged unless the local copy is outdated. A standard Commerce instance transfers around 300 KB per request, and traffic can quickly grow to over 1000 requests in some situations. With L2 caching, each web node stores frequently accessed data locally and uses the remote cache for two purposes: @@ -104,7 +104,7 @@ Where: For Adobe Commerce versions earlier than 2.4.9 that support Redis, Adobe recommends using Redis for remote caching (`\Magento\Framework\Cache\Backend\Redis`) and `Cm_Cache_Backend_File` for the local caching of data in shared memory, using: `'local_backend_options' => ['cache_dir' => '/dev/shm/']`. -Adobe recommends the use of the [`cache preload`](redis-pg-cache.md#redis-preload-feature) feature, as it drastically decreases the pressure on Redis. Do not forget to add the suffix `:hash` for preload keys. +The [`cache preload`](redis-pg-cache.md#redis-preload-feature) feature is a separate, independent mechanism that can be used with or without L2 caching. Where L2 caching reduces the size of each remote cache call, cache preload reduces the *number* of remote cache calls, by fetching a fixed list of cache IDs in a single pipelined batch instead of one round trip per ID. Adobe recommends enabling it, as it drastically decreases the number of round trips to Redis. Do not forget to add the suffix `:hash` for preload keys. ## Stale cache options