docs: describe what the volatile-lru eviction policy actually evicts

guides/hosting/infrastructure/redis.md

@@ -26,7 +26,7 @@ Please note that in current Redis versions, it is not possible to use different
 As ephemeral data can easily be restored and is most often used in cases where high performance matters, this data can be stored with no durable persistence.
 This means the data is only stored in memory and is lost when the Redis instance is restarted.
 
-For key eviction policy you should use `volatile-lru`, which only automatically deletes data that is expired, as the application explicitly manages the TTL for each cache item.
+For key eviction policy you should use `volatile-lru`, which only evicts keys that have a TTL (least recently used first) when the memory limit is reached, as the application explicitly manages the TTL for each cache item.
 
 The caching data (HTTP-Cache & Object cache) is what should be stored in this instance.
 
@@ -50,7 +50,7 @@ The session data is what should be stored in this instance.
 
 Again, this is durable data that cannot easily be recreated, therefore, it should be persisted as well.
 
-As the data is critical, it is important to use a key eviction policy that will not delete data that is not expired, therefore `volatile-lru` should be used.
+As the data is critical, it is important to use a key eviction policy that never evicts keys without a TTL, therefore `volatile-lru` should be used. Keep in mind that it can still evict the least recently used keys that do have a TTL.
 
 The cart, number range, lock store, and increment data are what should be stored in this instance.
 

guides/hosting/performance/caches.md

@@ -111,7 +111,7 @@ This is a Symfony cache pool configuration and therefore supports all adapters f
 ### Using Redis
 
 Redis is a very fast in-memory key-value store. It is a good choice for caching data that is frequently accessed and does not need to be persisted. Redis can be used as a cache adapter in Shopware. As the cached information is ephemeral and can be recreated, it is not necessary to configure Redis to store the data on disk. For maximum performance, you can configure Redis to use no persistence. Refer to the [Redis docs](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) for details.
-As key eviction policy, you should use `volatile-lru`. This policy only automatically deletes expired data, as the application explicitly manages the TTL for each cache item. For a detailed overview of Redis key eviction policies, see the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
+As key eviction policy, you should use `volatile-lru`. This policy only evicts keys that have a TTL (least recently used first) when the memory limit is reached, as the application explicitly manages the TTL for each cache item. For a detailed overview of Redis key eviction policies, see the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
 
 For `cache.adapter.redis_tag_aware` minimum Shopware 6.5.8.3 is required. Otherwise use `cache.adapter.redis`.
 

guides/hosting/performance/cart-storage.md

@@ -77,5 +77,5 @@ bin/console cart:migrate sql
 As the information stored here is durable and should be persistent, even in the case of a Redis restart, it is recommended to configure the used Redis instance that it will not just keep the data in memory, but also store it on the disk.
 This can be done by using snapshots (RDB) and Append Only Files (AOF), refer to the [Redis docs](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) for details.
 
-As key eviction policy you should use `volatile-lru`, which only automatically deletes carts that are expired, as otherwise you might risk of losing data.
+As key eviction policy you should use `volatile-lru`, which only evicts carts that have a TTL (least recently used first) when the memory limit is reached, as otherwise you might risk of losing data.
 For a detailed overview of Redis key eviction policies see the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).

guides/hosting/performance/increment.md

@@ -67,7 +67,7 @@ shopware:
 
 As the information stored here is durable and should be persistent, even in the case of a Redis restart, it is recommended to configure the used Redis instance that it will not just keep the data in memory, but also store it on the disk. This can be done by using snapshots (RDB) and Append Only Files (AOF), refer to the [Redis docs](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) for details.
 
-As key eviction policy you should use `volatile-lru`, which only automatically deletes data that is expired, as otherwise you might risk losing data. For a detailed overview of Redis key eviction policies refer to the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
+As key eviction policy you should use `volatile-lru`, which only evicts keys that have a TTL (least recently used first) when the memory limit is reached, as otherwise you might risk losing data. For a detailed overview of Redis key eviction policies refer to the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
 
 ## Disabling the increment storage
 

guides/hosting/performance/number-ranges.md

@@ -51,7 +51,7 @@ shopware:
 
 As the information stored here is durable and should be persistent, even in the case of a Redis restart, it is recommended to configure the used Redis instance that it will not just keep the data in memory, but also store it on the disk. This can be done by using snapshots (RDB) and Append Only Files (AOF), refer to the [Redis docs](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) for details.
 
-As key eviction policy you should use `volatile-lru`, which only automatically deletes data that is expired, as otherwise you might risk losing data. For a detailed overview of Redis key eviction policies refer to the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
+As key eviction policy you should use `volatile-lru`, which only evicts keys that have a TTL (least recently used first) when the memory limit is reached, as otherwise you might risk losing data. For a detailed overview of Redis key eviction policies refer to the [Redis docs](https://redis.io/docs/latest/develop/reference/eviction/).
 
 ## Migrating between storages