From 6ad185ef4755df41ac34a5b550ff711210e5f852 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Tue, 6 Aug 2024 15:46:50 +0100 Subject: [PATCH 01/22] DOC-4037 add new CSC page --- .../connect/clients/client-side-caching.md | 97 +++++++++++++++++++ static/images/CSCNoCache.drawio.svg | 4 + static/images/CSCWithCache.drawio.svg | 4 + 3 files changed, 105 insertions(+) create mode 100644 content/develop/connect/clients/client-side-caching.md create mode 100644 static/images/CSCNoCache.drawio.svg create mode 100644 static/images/CSCWithCache.drawio.svg diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md new file mode 100644 index 0000000000..14250d61e0 --- /dev/null +++ b/content/develop/connect/clients/client-side-caching.md @@ -0,0 +1,97 @@ +--- +categories: +- docs +- develop +- stack +- oss +- rs +- rc +- oss +- kubernetes +- clients +description: 'Server-assisted, client-side caching in Redis' +linkTitle: Client-side caching +title: Client-side caching in Redis +weight: 20 +--- + +*Client-side caching (CSC)* is a technique to allow faster communication +between a Redis client and the server. + +By default, an [application server](https://en.wikipedia.org/wiki/Application_server) +(which sits between the user app and the database) contacts the +Redis database server using the client library for every read request. +The diagram below shows the flow of communication from the user app, +through the application server to the database and back again: + +{{< image filename="images/CSCNoCache.drawio.svg" >}} + +When you use CSC, the client library +maintains its own local cache of data objects as it retrieves them +from the database. When the same objects are needed again, the client +can satisfy the read requests from the cache instead of the database: + +{{< image filename="images/CSCWithCache.drawio.svg" >}} + +Accessing the cache is much faster than communicating with the database over the +network. Also, this technique reduces the load on the database server, so you may +be able to run it using fewer nodes. + +As with other forms of [caching](https://en.wikipedia.org/wiki/Cache_(computing)), +CSC works well in the typical use case where a small subset of the data +gets used much more frequently than the rest of the data (according +to the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)). + +## Updating the cache when the data changes + +All caching systems must implement a scheme to update data in the cache +when the corresponding data changes in the main database. Redis uses an +approach called *tracking*. + +When CSC is enabled, the Redis server remembers or *tracks* the set of keys +that each client has previously read. This includes cases where the client +reads data directly, as with the [`GET`]({{< relref "/commands/get" >}}) +command, and also where the server calculates values from the stored data, +as with [`STRLEN`]({{< relref "/commands/strlen" >}}). When any client +writes new data to a tracked key, the server sends an invalidation message +to all clients that have accessed that key previously. This message warns +the clients that their cached copies of the data are no longer valid and the clients +will evict the stale data in response. Next time a client reads from +the same key, it will access the database directly and refresh its cache +with the updated data. + +## Which commands can cache data? + +All read-only commands (with the `@read` +[ACL category]({{< relref "/operate/oss_and_stack/management/security/acl" >}})) +will use cached data, except for the following: + +- Any commands for + [probabilistic data types]({{< relref "/develop/data-types/probabilistic" >}}). + These types are designed to be updated frequently, which means that caching + them gives little or no benefit. +- Non-deterministic commands (such as [`HSCAN`({{< relref "/commands/hscan" >}})) + and [`ZRANDMEMBER`]({{< relref "/commands/zrandmember" >}}). By design, these commands + give different results each time they are called. +- Search and query commands (with the `FT.*` prefix), such as + [`FT.SEARCH`]({{< relref "/commands/ft.search" >}}). + +You should also note that multi-key read commands such as +[`MGET`]({{< relref "/commands/mget" >}}) *do* cache data correctly but the +ordering of the keys is significant. For example `MGET name:1 name:2` is +cached separately from `MGET name:2 name:1` because the server retrieves the +values in the order you specify. + +You can use the [`MONITOR`]({{< relref "/commands/monitor" >}}) command to +check the server's behavior when you are using CSC. Because `MONITOR` only +reports activity from the server, you should find that the first cacheable +access to a key causes a response from the server. However, subsequent +accesses are satisfied by the cache, and so `MONITOR` should report no +server activity. + +## Enabling CSC + +Use the [`CLIENT TRACKING`]({{< relref "/commands/client-tracking" >}}) +command to enable CSC from [`redis-cli`]({{< relref "/develop/connect/cli" >}}). +You can also enable CSC when you connect to a server from one of the Redis +client libraries. diff --git a/static/images/CSCNoCache.drawio.svg b/static/images/CSCNoCache.drawio.svg new file mode 100644 index 0000000000..9c07350368 --- /dev/null +++ b/static/images/CSCNoCache.drawio.svg @@ -0,0 +1,4 @@ + + + +
App
App
Application server
Application server
App
backend
App...
Redis
client
Redis...
Read request
Read request
Response
ResponseText is not SVG - cannot display \ No newline at end of file diff --git a/static/images/CSCWithCache.drawio.svg b/static/images/CSCWithCache.drawio.svg new file mode 100644 index 0000000000..5f0349967e --- /dev/null +++ b/static/images/CSCWithCache.drawio.svg @@ -0,0 +1,4 @@ + + + +
App
App
Application server
Application server
App
backend
App...
Redis
client
Redis...
Cache
Cache
Read request
Read request
Response
Response
Reduced
network
traffic
Reduced...
Lower latency
Lower latencyText is not SVG - cannot display \ No newline at end of file From 91e332cd6f48ed9c00fb788ef93214222a7f91b0 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Wed, 7 Aug 2024 13:12:55 +0100 Subject: [PATCH 02/22] DOC-4037 added sequence diagram --- content/develop/connect/clients/client-side-caching.md | 9 +++++++-- static/images/CSCSeqDiagram.drawio.svg | 4 ++++ 2 files changed, 11 insertions(+), 2 deletions(-) create mode 100644 static/images/CSCSeqDiagram.drawio.svg diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 14250d61e0..ac7dc7b081 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -60,6 +60,11 @@ will evict the stale data in response. Next time a client reads from the same key, it will access the database directly and refresh its cache with the updated data. +The sequence diagram below shows how two clients might interact as they +access and update the same key: + +{{< image filename="images/CSCSeqDiagram.drawio.svg" >}} + ## Which commands can cache data? All read-only commands (with the `@read` @@ -70,13 +75,13 @@ will use cached data, except for the following: [probabilistic data types]({{< relref "/develop/data-types/probabilistic" >}}). These types are designed to be updated frequently, which means that caching them gives little or no benefit. -- Non-deterministic commands (such as [`HSCAN`({{< relref "/commands/hscan" >}})) +- Non-deterministic commands (such as [`HSCAN`]({{< relref "/commands/hscan" >}})) and [`ZRANDMEMBER`]({{< relref "/commands/zrandmember" >}}). By design, these commands give different results each time they are called. - Search and query commands (with the `FT.*` prefix), such as [`FT.SEARCH`]({{< relref "/commands/ft.search" >}}). -You should also note that multi-key read commands such as +Also note that multi-key read commands such as [`MGET`]({{< relref "/commands/mget" >}}) *do* cache data correctly but the ordering of the keys is significant. For example `MGET name:1 name:2` is cached separately from `MGET name:2 name:1` because the server retrieves the diff --git a/static/images/CSCSeqDiagram.drawio.svg b/static/images/CSCSeqDiagram.drawio.svg new file mode 100644 index 0000000000..744fc59b7c --- /dev/null +++ b/static/images/CSCSeqDiagram.drawio.svg @@ -0,0 +1,4 @@ + + + +
Client A cache
Client A cache
Client A
Client A
Redis database
Redis database
DB tracks Client A
D...
DB tracks Client B
D...
Client B
Client B
Client B cache
Client B cache
SET city Paris
SET city Pa...
GET city
GET city
"Paris"
"Paris"
CACHE city Paris
CACHE city...
"Not cached"
"Not cached"
GET city
GET city
GET city
GET city
"Not cached"
"Not cached"
GET city
GET city
"Paris"
"Paris"
CACHE city Paris
CACHE city...
SET city Berlin
SET city Be...
INVALIDATE city
INVALIDATE...
INVALIDATE city
INVALIDATE...
DELETE city
DELETE city
DELETE city
DELETE city
GET city
GET city
"Not cached"
"Not cached"
GET city
GET city
"Berlin"
"Berlin"
CACHE city Berlin
CACHE city...
GET city
GET city
"Berlin"
"Berlin"Text is not SVG - cannot display \ No newline at end of file From 51b9348da10db811390cf73cf96d255a1469917a Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Thu, 8 Aug 2024 14:02:54 +0100 Subject: [PATCH 03/22] DOC-4037 add Python guide and other minor content changes --- .../connect/clients/client-side-caching.md | 125 +++++++++++++++--- .../connect/clients/python/redis-py.md | 62 +++++++++ .../{use => reference}/client-side-caching.md | 9 +- 3 files changed, 175 insertions(+), 21 deletions(-) rename content/develop/{use => reference}/client-side-caching.md (98%) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index ac7dc7b081..f1387c6b6a 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -9,26 +9,26 @@ categories: - oss - kubernetes - clients -description: 'Server-assisted, client-side caching in Redis' +description: Server-assisted, client-side caching in Redis linkTitle: Client-side caching -title: Client-side caching in Redis +title: Client-side caching introduction weight: 20 --- -*Client-side caching (CSC)* is a technique to allow faster communication -between a Redis client and the server. +*Client-side caching* is a technique to reduce network traffic between +a Redis client and the server. This generally gives better performance. By default, an [application server](https://en.wikipedia.org/wiki/Application_server) (which sits between the user app and the database) contacts the -Redis database server using the client library for every read request. +Redis database server through the client library for every read request. The diagram below shows the flow of communication from the user app, through the application server to the database and back again: {{< image filename="images/CSCNoCache.drawio.svg" >}} When you use CSC, the client library -maintains its own local cache of data objects as it retrieves them -from the database. When the same objects are needed again, the client +maintains its own local cache of data items as it retrieves them +from the database. When the same items are needed again, the client can satisfy the read requests from the cache instead of the database: {{< image filename="images/CSCWithCache.drawio.svg" >}} @@ -38,8 +38,8 @@ network. Also, this technique reduces the load on the database server, so you ma be able to run it using fewer nodes. As with other forms of [caching](https://en.wikipedia.org/wiki/Cache_(computing)), -CSC works well in the typical use case where a small subset of the data -gets used much more frequently than the rest of the data (according +CSC works well in the very common use case where a small subset of the data +gets accessed much more frequently than the rest of the data (according to the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)). ## Updating the cache when the data changes @@ -49,7 +49,7 @@ when the corresponding data changes in the main database. Redis uses an approach called *tracking*. When CSC is enabled, the Redis server remembers or *tracks* the set of keys -that each client has previously read. This includes cases where the client +that each client connection has previously read. This includes cases where the client reads data directly, as with the [`GET`]({{< relref "/commands/get" >}}) command, and also where the server calculates values from the stored data, as with [`STRLEN`]({{< relref "/commands/strlen" >}}). When any client @@ -75,28 +75,113 @@ will use cached data, except for the following: [probabilistic data types]({{< relref "/develop/data-types/probabilistic" >}}). These types are designed to be updated frequently, which means that caching them gives little or no benefit. -- Non-deterministic commands (such as [`HSCAN`]({{< relref "/commands/hscan" >}})) +- Non-deterministic commands such as [`HSCAN`]({{< relref "/commands/hscan" >}}) and [`ZRANDMEMBER`]({{< relref "/commands/zrandmember" >}}). By design, these commands give different results each time they are called. - Search and query commands (with the `FT.*` prefix), such as - [`FT.SEARCH`]({{< relref "/commands/ft.search" >}}). - -Also note that multi-key read commands such as -[`MGET`]({{< relref "/commands/mget" >}}) *do* cache data correctly but the -ordering of the keys is significant. For example `MGET name:1 name:2` is -cached separately from `MGET name:2 name:1` because the server retrieves the -values in the order you specify. + [`FT.SEARCH`]({{< baseurl >}}/commands/ft.search). You can use the [`MONITOR`]({{< relref "/commands/monitor" >}}) command to check the server's behavior when you are using CSC. Because `MONITOR` only reports activity from the server, you should find that the first cacheable access to a key causes a response from the server. However, subsequent accesses are satisfied by the cache, and so `MONITOR` should report no -server activity. +server activity if CSC is working correctly. + +## What data gets cached for a command? + +Broadly speaking, the data from the *specific response* to a command invocation +gets cached after it is used for the first time. Subsets of that data +or values calculated from it are retrieved from the server as usual and +then cached separately. For example: + +- The whole string retrieved by [`GET`]({{< relref "/commands/get" >}}) + is added to the cache. Parts of the same string retrieved by + [`SUBSTR`]({{< relref "/commands/substr" >}}) are calculated on the + server the first time and then cached separately from the original + string. +- Using [`GETBIT`]({{< relref "/commands/getbit" >}}) or + [`BITFIELD`]({{< relref "/commands/bitfield" >}}) on a string + caches the returned values separately from the original string. +- For composite data types accessed by keys + ([hash]({{< relref "/develop/data-types/hashes" >}}), + [JSON]({{< relref "/develop/data-types/json" >}}), + [set]({{< relref "/develop/data-types/sets" >}}), and + [sorted set]({{< relref "/develop/data-types/sorted-sets" >}})), + the whole object is cached separately from the individual fields. + So the results of `HGETALL mykey` and `HGET mykey myfield` create + separate entries in the cache. +- Ranges from [lists]({{< relref "/develop/data-types/lists" >}}), + [streams]({{< relref "/develop/data-types/streams" >}}), + and [sorted sets]({{< relref "/develop/data-types/sorted-sets" >}}) + are cached separately from the object they form a part of. Likewise, + subsets returned by [`SINTER`]({{< relref "/commands/sinter" >}}) and + [`SDIFF`]({{< relref "/commands/sdiff" >}}) create separate cache entries. +- For multi-key read commands such as [`MGET`]({{< relref "/commands/mget" >}}), + the ordering of the keys is significant. For example `MGET name:1 name:2` is + cached separately from `MGET name:2 name:1` because the server returns the + values in the order you specify. +- Boolean or numeric values calculated from data types (for example + [`SISMEMBER`]({{< relref "/commands/sismember" >}})) and + [`LLEN`]({{< relref "/commands/llen" >}}) are cached separately from the + object they refer to. + ## Enabling CSC Use the [`CLIENT TRACKING`]({{< relref "/commands/client-tracking" >}}) command to enable CSC from [`redis-cli`]({{< relref "/develop/connect/cli" >}}). You can also enable CSC when you connect to a server from one of the Redis -client libraries. +[client libraries]({{< relref "/develop/connect/clients" >}}). + +## Usage recommendations + +Like any caching system, CSC has some limitations: + +- The cache has only a limited amount of memory available. When the limit + is reached, the client must *evict* potentially useful items from the + cache to make room for new ones. +- Cache misses, tracking, and invalidation messages always add a slight + performance penalty. + +Below are a few guidelines to help you use CSC efficiently, within these +limitations: + +- **Use a separate connection for data that is not cache-friendly**: + Caching gives the most benefit + for keys that are read frequently and updated infrequently. However, you + may also have data such as counters and scoreboards that receive frequent + updates. In cases like this, the performance overhead of the invalidation + messages can be greater than the savings made by caching. Avoid this problem + by using a separate connection *without* CSC for any data that is + not cache-friendly. +- **Set a maximum time-to-live (TTL) for cached items**: The client libraries + let you set a *time-to-live (TTL)* value for items in the cache. This is + the maximum time between cache reads for any particular key. If a key + isn't accessed during its TTL period, it will be deleted from the cache + automatically and the memory that it uses will be freed. Re-using cache + memory like this is more efficient than evicting items when the cache + gets full. The exact TTL value depends on your specific requirements, but + bear in mind that the whole purpose of the cache is to optimize reads for + data that you access frequently. By definition, data that needs a long + TTL isn't accessed frequently. +- **Estimate how many items you can cache**: The client libraries let you + specify the maximum number of items you want to hold in the cache. You + can calculate an estimate for this number by dividing the + maximum desired size of the + cache in memory by the average size of the items you want to store + (use the [`MEMORY USAGE`]({{< relref "/commands/memory-usage" >}}) + command to get the memory footprint of a key). So, if you had + 10MB (or 10485760 bytes) available for the cache, and the average + size of an item was 80 bytes, you could fit approximately + 10485760 / 80 = 131072 items in the cache. Monitor memory usage + on your server with a realistic test load to adjust your estimate + up or down. + + ## Reference + + The Redis server implements extra features for CSC that are not used by + the main Redis clients, but may be useful for custom clients and other + advanced applications. See + [Client-side caching reference]({{< relref "/develop/reference/client-side-caching" >}}) + for a full technical guide to all the options available for CSC. diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index 06c7602362..e219d6db76 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -119,6 +119,68 @@ r.get('foo') ``` For more information, see [redis-py TLS examples](https://redis-py.readthedocs.io/en/stable/examples/ssl_connection_examples.html). +## Connect using client-side caching (CSC) + +*Client-side caching* is a technique to reduce network traffic between +the client and server, resulting in better performance. See +[Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) +for more information about how CSC works and how to use it effectively. + +To enable CSC, you simply need to add a few extra parameters when you connect +to the server: + +- `protocol`: (Required) You must pass a value of `3` here because + CSC requires the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) + protocol. +- `cache_enabled`: (Required) Pass a `True` value here to enable CSC +- `cache_ttl`: (Recommended) Time-to-live (TTL) between reads for items in the cache, + measured in seconds. This defaults to zero (indicating that items in the cache never expire) + but it is strongly recommended that you choose a realistic TTL for + your needs. See + [Usage recommendations]({{< relref "/develop/connect/clients/client-side-caching#usage-recommendations" >}}) + for more information. + +The example below shows the simplest CSC connection to the default host and port, +`localhost:6379`. +All of the connection variants described above accept these parameters, so you can +use CSC with a connection pool or a cluster connection in exactly the same way. + +```python +r = redis.Redis( + protocol=3, + cache_enabled=True, + cache_ttl=180, + decode_responses=True +) + +r.set("city", "New York") +cityNameAttempt1 = r.get("city") # Retrieved from Redis server and cached +cityNameAttempt2 = r.get("city") # Retrieved from cache +``` + +You can see the cache working if you connect to the same Redis database +with [`redis-cli`]({{< relref "/develop/connect/cli" >}}) and run the +[`MONITOR`]({{< relref "/commands/monitor" >}}) command. If you run the +code above with the `cache_enabled` line commented out, you should see +the following in the CLI among the output from `MONITOR`: + +``` +1723109720.268903 [...] "SET" "city" "New York" +1723109720.269681 [...] "GET" "city" +1723109720.270205 [...] "GET" "city" +``` + +This shows that the server responds to both `get("city")` calls. +If you the code again with `cache_enabled` uncommented, you will see + +``` +1723110248.712663 [...] "SET" "city" "New York" +1723110248.713607 [...] "GET" "city" +``` + +This shows that the first `get("city")` call contacted the server but the second +call was satisfied by the cache. + ## Example: Indexing and querying JSON documents Make sure that you have Redis Stack and `redis-py` installed. Import dependencies: diff --git a/content/develop/use/client-side-caching.md b/content/develop/reference/client-side-caching.md similarity index 98% rename from content/develop/use/client-side-caching.md rename to content/develop/reference/client-side-caching.md index 224adc7f8f..c8fe2dd0a9 100644 --- a/content/develop/use/client-side-caching.md +++ b/content/develop/reference/client-side-caching.md @@ -13,10 +13,17 @@ description: 'Server-assisted, client-side caching in Redis ' linkTitle: Client-side caching -title: Client-side caching in Redis +title: Client-side caching reference +aliases: /develop/use/client-side-caching/ weight: 2 --- +{{}}This document is intended as an in-depth reference for +client-side caching. See +[Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) +for general usage guidelines. +{{}} + Client-side caching is a technique used to create high performance services. It exploits the memory available on application servers, servers that are usually distinct computers compared to the database nodes, to store some subset From 487a51b0ab2f497bdfad9293ebb2daed8449bbd7 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Thu, 8 Aug 2024 15:13:39 +0100 Subject: [PATCH 04/22] DOC-4037 put image files into a subfolder for CSC --- content/develop/connect/clients/client-side-caching.md | 6 +++--- static/images/{ => csc}/CSCNoCache.drawio.svg | 0 static/images/{ => csc}/CSCSeqDiagram.drawio.svg | 0 static/images/{ => csc}/CSCWithCache.drawio.svg | 0 4 files changed, 3 insertions(+), 3 deletions(-) rename static/images/{ => csc}/CSCNoCache.drawio.svg (100%) rename static/images/{ => csc}/CSCSeqDiagram.drawio.svg (100%) rename static/images/{ => csc}/CSCWithCache.drawio.svg (100%) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index f1387c6b6a..1f5fc2b78d 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -24,14 +24,14 @@ Redis database server through the client library for every read request. The diagram below shows the flow of communication from the user app, through the application server to the database and back again: -{{< image filename="images/CSCNoCache.drawio.svg" >}} +{{< image filename="images/csc/CSCNoCache.drawio.svg" >}} When you use CSC, the client library maintains its own local cache of data items as it retrieves them from the database. When the same items are needed again, the client can satisfy the read requests from the cache instead of the database: -{{< image filename="images/CSCWithCache.drawio.svg" >}} +{{< image filename="images/csc/CSCWithCache.drawio.svg" >}} Accessing the cache is much faster than communicating with the database over the network. Also, this technique reduces the load on the database server, so you may @@ -63,7 +63,7 @@ with the updated data. The sequence diagram below shows how two clients might interact as they access and update the same key: -{{< image filename="images/CSCSeqDiagram.drawio.svg" >}} +{{< image filename="images/csc/CSCSeqDiagram.drawio.svg" >}} ## Which commands can cache data? diff --git a/static/images/CSCNoCache.drawio.svg b/static/images/csc/CSCNoCache.drawio.svg similarity index 100% rename from static/images/CSCNoCache.drawio.svg rename to static/images/csc/CSCNoCache.drawio.svg diff --git a/static/images/CSCSeqDiagram.drawio.svg b/static/images/csc/CSCSeqDiagram.drawio.svg similarity index 100% rename from static/images/CSCSeqDiagram.drawio.svg rename to static/images/csc/CSCSeqDiagram.drawio.svg diff --git a/static/images/CSCWithCache.drawio.svg b/static/images/csc/CSCWithCache.drawio.svg similarity index 100% rename from static/images/CSCWithCache.drawio.svg rename to static/images/csc/CSCWithCache.drawio.svg From 2897cc7f5d29ffdb67230ee445ccb834b62c6ad4 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Thu, 15 Aug 2024 16:41:11 +0100 Subject: [PATCH 05/22] DOC-4037 implemented feedback and added Jedis stuff --- .../connect/clients/client-side-caching.md | 32 ++--- content/develop/connect/clients/java/jedis.md | 123 ++++++++++++++++++ .../connect/clients/python/redis-py.md | 54 ++++++-- 3 files changed, 178 insertions(+), 31 deletions(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 1f5fc2b78d..20e290ad5c 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -17,6 +17,8 @@ weight: 20 *Client-side caching* is a technique to reduce network traffic between a Redis client and the server. This generally gives better performance. +See [Client-side caching compatibility with Redis Software and Redis Cloud]({{< relref "operate/rs/references/compatibility/client-side-caching" >}}) +for details of the Redis versions that support CSC. By default, an [application server](https://en.wikipedia.org/wiki/Application_server) (which sits between the user app and the database) contacts the @@ -34,8 +36,9 @@ can satisfy the read requests from the cache instead of the database: {{< image filename="images/csc/CSCWithCache.drawio.svg" >}} Accessing the cache is much faster than communicating with the database over the -network. Also, this technique reduces the load on the database server, so you may -be able to run it using fewer nodes. +network and it reduces network traffic. Also, this technique reduces +the load on the database server, so you may be able to run it using fewer hardware +resources. As with other forms of [caching](https://en.wikipedia.org/wiki/Cache_(computing)), CSC works well in the very common use case where a small subset of the data @@ -75,7 +78,8 @@ will use cached data, except for the following: [probabilistic data types]({{< relref "/develop/data-types/probabilistic" >}}). These types are designed to be updated frequently, which means that caching them gives little or no benefit. -- Non-deterministic commands such as [`HSCAN`]({{< relref "/commands/hscan" >}}) +- Non-deterministic commands such as [`HGETALL`]({{< relref "/commands/hgetall" >}}), + [`HSCAN`]({{< relref "/commands/hscan" >}}), and [`ZRANDMEMBER`]({{< relref "/commands/zrandmember" >}}). By design, these commands give different results each time they are called. - Search and query commands (with the `FT.*` prefix), such as @@ -109,7 +113,7 @@ then cached separately. For example: [set]({{< relref "/develop/data-types/sets" >}}), and [sorted set]({{< relref "/develop/data-types/sorted-sets" >}})), the whole object is cached separately from the individual fields. - So the results of `HGETALL mykey` and `HGET mykey myfield` create + So the results of `JSON.GET mykey $` and `JSON.GET mykey $.myfield` create separate entries in the cache. - Ranges from [lists]({{< relref "/develop/data-types/lists" >}}), [streams]({{< relref "/develop/data-types/streams" >}}), @@ -126,14 +130,6 @@ then cached separately. For example: [`LLEN`]({{< relref "/commands/llen" >}}) are cached separately from the object they refer to. - -## Enabling CSC - -Use the [`CLIENT TRACKING`]({{< relref "/commands/client-tracking" >}}) -command to enable CSC from [`redis-cli`]({{< relref "/develop/connect/cli" >}}). -You can also enable CSC when you connect to a server from one of the Redis -[client libraries]({{< relref "/develop/connect/clients" >}}). - ## Usage recommendations Like any caching system, CSC has some limitations: @@ -144,7 +140,7 @@ Like any caching system, CSC has some limitations: - Cache misses, tracking, and invalidation messages always add a slight performance penalty. -Below are a few guidelines to help you use CSC efficiently, within these +Below are some guidelines to help you use CSC efficiently, within these limitations: - **Use a separate connection for data that is not cache-friendly**: @@ -155,16 +151,6 @@ limitations: messages can be greater than the savings made by caching. Avoid this problem by using a separate connection *without* CSC for any data that is not cache-friendly. -- **Set a maximum time-to-live (TTL) for cached items**: The client libraries - let you set a *time-to-live (TTL)* value for items in the cache. This is - the maximum time between cache reads for any particular key. If a key - isn't accessed during its TTL period, it will be deleted from the cache - automatically and the memory that it uses will be freed. Re-using cache - memory like this is more efficient than evicting items when the cache - gets full. The exact TTL value depends on your specific requirements, but - bear in mind that the whole purpose of the cache is to optimize reads for - data that you access frequently. By definition, data that needs a long - TTL isn't accessed frequently. - **Estimate how many items you can cache**: The client libraries let you specify the maximum number of items you want to hold in the cache. You can calculate an estimate for this number by dividing the diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index 13f36cc097..bf742e0591 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -196,6 +196,129 @@ public class Main { } ``` +## Connect using client-side caching (CSC) + +*Client-side caching* is a technique to reduce network traffic between +the client and server, resulting in better performance. See +[Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) +for more information about how CSC works and how to use it effectively. + +To enable CSC, you simply need to specify the +[RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) +protocol and pass a suitable cache instance during the connection. Jedis supports +the [Guava](https://mvnrepository.com/artifact/com.google.guava/guava) +and [Caffeine](https://mvnrepository.com/artifact/com.github.ben-manes.caffeine/caffeine) +cache libraries for CSC. + +The example below shows the simplest CSC connection to the default host and port, +`localhost:6379`, using a Guava cache. +All of the connection variants described above accept these parameters, so you can +use CSC with a connection pool or a cluster connection in exactly the same way. + +```java +// Connection details. +HostAndPort node = HostAndPort.from("localhost:6379"); +JedisClientConfig clientConfig = DefaultJedisClientConfig.builder() + .resp3() // RESP3 protocol + .build(); + +// Create a Guava cache instance (see below for Caffeine equivalent). +GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder() + .maximumSize(1000) + .build(); + +UnifiedJedis client = new UnifiedJedis(node, + clientConfig, + clientSideCache); +``` + +If you prefer to use a Caffeine cache then the code to create it is very +similar: + +```java +CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder() + .maximumSize(1000) + .build(); +``` + +Once you have connected, the usual Redis commands will work transparently +with the cache: + +```java +client.set("city", "New York"); +client.get("city"); // Retrieved from Redis server and cached +client.get("city"); // Retrieved from cache +``` + +You can see the cache working if you connect to the same Redis database +with [`redis-cli`]({{< relref "/develop/connect/cli" >}}) and run the +[`MONITOR`]({{< relref "/commands/monitor" >}}) command. If you run the +code above but without passing `clientSideCache` during the connection, +you should see the following in the CLI among the output from `MONITOR`: + +``` +1723109720.268903 [...] "SET" "city" "New York" +1723109720.269681 [...] "GET" "city" +1723109720.270205 [...] "GET" "city" +``` + +This shows that the server responds to both `get("city")` calls. +If you run the code with `clientSideCache` added in again, you will see + +``` +1723110248.712663 [...] "SET" "city" "New York" +1723110248.713607 [...] "GET" "city" +``` + +This shows that the first `get("city")` call contacted the server but the second +call was satisfied by the cache. + +### Removing items from the cache + +You can remove one or more individual keys from the cache with the +`invalidate()` method of the cache object. This removes all cached items associated +with each specified key, so all results from multi-key commands (such as +[`MGET`]({{< relref "/commands/mget" >}})) and composite data structures +(such as [hashes]({{< relref "/develop/data-types/hashes" >}})) will be +cleared at once. The example below shows the effect of removing a single +key from the cache: + +```java +client.hget("person:1", "name"); // Read from the server +client.hget("person:1", "name"); // Read from the cache + +client.hget("person:2", "name"); // Read from the server +client.hget("person:2", "name"); // Read from the cache + +List keysList = new ArrayList<>(); +keysList.add("person:1".getBytes()); +clientSideCache.invalidate(keysList); + +client.hget("person:1", "name"); // Read from the server +client.hget("person:1", "name"); // Read from the cache + +client.hget("person:2", "name"); // Still read from the cache +``` + +You can also clear all cached items using the `clear()` +method: + +```java +client.hget("person:1", "name"); // Read from the server +client.hget("person:1", "name"); // Read from the cache + +client.hget("person:2", "name"); // Read from the server +client.hget("person:2", "name"); // Read from the cache + +clientSideCache.clear(); + +client.hget("person:1", "name"); // Read from the server +client.hget("person:1", "name"); // Read from the cache + +client.hget("person:2", "name"); // Read from the server +client.hget("person:2", "name"); // Read from the cache +``` + ## Production usage The following sections explain how to handle situations that may occur diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index e219d6db76..773c983601 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -133,12 +133,6 @@ to the server: CSC requires the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) protocol. - `cache_enabled`: (Required) Pass a `True` value here to enable CSC -- `cache_ttl`: (Recommended) Time-to-live (TTL) between reads for items in the cache, - measured in seconds. This defaults to zero (indicating that items in the cache never expire) - but it is strongly recommended that you choose a realistic TTL for - your needs. See - [Usage recommendations]({{< relref "/develop/connect/clients/client-side-caching#usage-recommendations" >}}) - for more information. The example below shows the simplest CSC connection to the default host and port, `localhost:6379`. @@ -149,7 +143,6 @@ use CSC with a connection pool or a cluster connection in exactly the same way. r = redis.Redis( protocol=3, cache_enabled=True, - cache_ttl=180, decode_responses=True ) @@ -171,7 +164,7 @@ the following in the CLI among the output from `MONITOR`: ``` This shows that the server responds to both `get("city")` calls. -If you the code again with `cache_enabled` uncommented, you will see +If you run the code again with `cache_enabled` uncommented, you will see ``` 1723110248.712663 [...] "SET" "city" "New York" @@ -181,6 +174,51 @@ If you the code again with `cache_enabled` uncommented, you will see This shows that the first `get("city")` call contacted the server but the second call was satisfied by the cache. +### Removing items from the cache + +You can remove individual keys from the cache with the +`invalidate_key_from_cache()` method. This removes all cached items associated +with the key, so all results from multi-key commands (such as +[`MGET`]({{< relref "/commands/mget" >}})) and composite data structures +(such as [hashes]({{< relref "/develop/data-types/hashes" >}})) will be +cleared at once. The example below shows the effect of removing a single +key from the cache: + +```python +r.hget("person:1", "name") # Read from the server +r.hget("person:1", "name") # Read from the cache + +r.hget("person:2", "name") # Read from the server +r.hget("person:2", "name") # Read from the cache + +r.invalidate_key_from_cache("person:1") + +r.hget("person:1", "name") # Read from the server +r.hget("person:1", "name") # Read from the cache + +r.hget("person:2", "name") # Still read from the cache +``` + +You can also clear all cached items using the `flush_cache()` +method: + +```python +r.hget("person:1", "name") # Read from the server +r.hget("person:1", "name") # Read from the cache + +r.hget("person:2", "name") # Read from the cache +r.hget("person:2", "name") # Read from the cache + +r.flush_cache() + +r.hget("person:1", "name") # Read from the server +r.hget("person:1", "name") # Read from the cache + +r.hget("person:2", "name") # Read from the server +r.hget("person:2", "name") # Read from the cache +``` + + ## Example: Indexing and querying JSON documents Make sure that you have Redis Stack and `redis-py` installed. Import dependencies: From ce99d3803892d4471f6e32a76e6b8b4995dff494 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Fri, 13 Sep 2024 13:02:05 +0100 Subject: [PATCH 06/22] DOC-4037 updated code samples --- content/develop/connect/clients/java/jedis.md | 55 +++++++------------ .../connect/clients/python/redis-py.md | 25 +++++---- 2 files changed, 35 insertions(+), 45 deletions(-) diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index bf742e0591..ad614ae1cd 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -205,40 +205,25 @@ for more information about how CSC works and how to use it effectively. To enable CSC, you simply need to specify the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) -protocol and pass a suitable cache instance during the connection. Jedis supports -the [Guava](https://mvnrepository.com/artifact/com.google.guava/guava) -and [Caffeine](https://mvnrepository.com/artifact/com.github.ben-manes.caffeine/caffeine) -cache libraries for CSC. +protocol and pass a cache configuration object during the connection. The example below shows the simplest CSC connection to the default host and port, -`localhost:6379`, using a Guava cache. +`localhost:6379`. All of the connection variants described above accept these parameters, so you can use CSC with a connection pool or a cluster connection in exactly the same way. ```java -// Connection details. -HostAndPort node = HostAndPort.from("localhost:6379"); -JedisClientConfig clientConfig = DefaultJedisClientConfig.builder() - .resp3() // RESP3 protocol - .build(); - -// Create a Guava cache instance (see below for Caffeine equivalent). -GuavaClientSideCache clientSideCache = GuavaClientSideCache.builder() - .maximumSize(1000) - .build(); - -UnifiedJedis client = new UnifiedJedis(node, - clientConfig, - clientSideCache); -``` +HostAndPort endpoint = new HostAndPort("localhost", 6379); -If you prefer to use a Caffeine cache then the code to create it is very -similar: +DefaultJedisClientConfig config = DefaultJedisClientConfig + .builder() + .password("secretPassword") + .protocol(RedisProtocol.RESP3) + .build(); -```java -CaffeineClientSideCache clientSideCache = CaffeineClientSideCache.builder() - .maximumSize(1000) - .build(); +CacheConfig cacheConfig = CacheConfig.builder().maxSize(1000).build(); + +UnifiedJedis client = new UnifiedJedis(endpoint, config, cacheConfig); ``` Once you have connected, the usual Redis commands will work transparently @@ -253,7 +238,7 @@ client.get("city"); // Retrieved from cache You can see the cache working if you connect to the same Redis database with [`redis-cli`]({{< relref "/develop/connect/cli" >}}) and run the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. If you run the -code above but without passing `clientSideCache` during the connection, +code above but without passing `cacheConfig` during the connection, you should see the following in the CLI among the output from `MONITOR`: ``` @@ -263,7 +248,7 @@ you should see the following in the CLI among the output from `MONITOR`: ``` This shows that the server responds to both `get("city")` calls. -If you run the code with `clientSideCache` added in again, you will see +If you run the code with `cacheConfig` added in again, you will see ``` 1723110248.712663 [...] "SET" "city" "New York" @@ -275,8 +260,8 @@ call was satisfied by the cache. ### Removing items from the cache -You can remove one or more individual keys from the cache with the -`invalidate()` method of the cache object. This removes all cached items associated +You can remove individual keys from the cache with the +`deleteByRedisKey()` method of the cache object. This removes all cached items associated with each specified key, so all results from multi-key commands (such as [`MGET`]({{< relref "/commands/mget" >}})) and composite data structures (such as [hashes]({{< relref "/develop/data-types/hashes" >}})) will be @@ -290,9 +275,8 @@ client.hget("person:1", "name"); // Read from the cache client.hget("person:2", "name"); // Read from the server client.hget("person:2", "name"); // Read from the cache -List keysList = new ArrayList<>(); -keysList.add("person:1".getBytes()); -clientSideCache.invalidate(keysList); +Cache myCache = client.getCache(); +myCache.deleteByRedisKey("person:1"); client.hget("person:1", "name"); // Read from the server client.hget("person:1", "name"); // Read from the cache @@ -300,7 +284,7 @@ client.hget("person:1", "name"); // Read from the cache client.hget("person:2", "name"); // Still read from the cache ``` -You can also clear all cached items using the `clear()` +You can also clear all cached items using the `flush()` method: ```java @@ -310,7 +294,8 @@ client.hget("person:1", "name"); // Read from the cache client.hget("person:2", "name"); // Read from the server client.hget("person:2", "name"); // Read from the cache -clientSideCache.clear(); +Cache myCache = client.getCache(); +myCache.flush(); client.hget("person:1", "name"); // Read from the server client.hget("person:1", "name"); // Read from the cache diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index 773c983601..e3a1fdd067 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -126,13 +126,13 @@ the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) for more information about how CSC works and how to use it effectively. -To enable CSC, you simply need to add a few extra parameters when you connect +To enable CSC, you simply need to add some extra parameters when you connect to the server: - `protocol`: (Required) You must pass a value of `3` here because CSC requires the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) protocol. -- `cache_enabled`: (Required) Pass a `True` value here to enable CSC +- `cache_config`: (Required) Pass `cache_config=CacheConfig()` here to enable CSC. The example below shows the simplest CSC connection to the default host and port, `localhost:6379`. @@ -140,9 +140,12 @@ All of the connection variants described above accept these parameters, so you c use CSC with a connection pool or a cluster connection in exactly the same way. ```python +import redis +from redis.cache import CacheConfig + r = redis.Redis( protocol=3, - cache_enabled=True, + cache_config=CacheConfig(), decode_responses=True ) @@ -154,7 +157,7 @@ cityNameAttempt2 = r.get("city") # Retrieved from cache You can see the cache working if you connect to the same Redis database with [`redis-cli`]({{< relref "/develop/connect/cli" >}}) and run the [`MONITOR`]({{< relref "/commands/monitor" >}}) command. If you run the -code above with the `cache_enabled` line commented out, you should see +code above with the `cache_config` line commented out, you should see the following in the CLI among the output from `MONITOR`: ``` @@ -164,7 +167,7 @@ the following in the CLI among the output from `MONITOR`: ``` This shows that the server responds to both `get("city")` calls. -If you run the code again with `cache_enabled` uncommented, you will see +If you run the code again with `cache_config` uncommented, you will see ``` 1723110248.712663 [...] "SET" "city" "New York" @@ -177,8 +180,8 @@ call was satisfied by the cache. ### Removing items from the cache You can remove individual keys from the cache with the -`invalidate_key_from_cache()` method. This removes all cached items associated -with the key, so all results from multi-key commands (such as +`delete_by_redis_keys()` method. This removes all cached items associated +with the keys, so all results from multi-key commands (such as [`MGET`]({{< relref "/commands/mget" >}})) and composite data structures (such as [hashes]({{< relref "/develop/data-types/hashes" >}})) will be cleared at once. The example below shows the effect of removing a single @@ -191,7 +194,8 @@ r.hget("person:1", "name") # Read from the cache r.hget("person:2", "name") # Read from the server r.hget("person:2", "name") # Read from the cache -r.invalidate_key_from_cache("person:1") +cache = r.get_cache() +cache.delete_by_redis_keys(["person:1"]) r.hget("person:1", "name") # Read from the server r.hget("person:1", "name") # Read from the cache @@ -199,7 +203,7 @@ r.hget("person:1", "name") # Read from the cache r.hget("person:2", "name") # Still read from the cache ``` -You can also clear all cached items using the `flush_cache()` +You can also clear all cached items using the `flush()` method: ```python @@ -209,7 +213,8 @@ r.hget("person:1", "name") # Read from the cache r.hget("person:2", "name") # Read from the cache r.hget("person:2", "name") # Read from the cache -r.flush_cache() +cache = r.get_cache() +cache.flush() r.hget("person:1", "name") # Read from the server r.hget("person:1", "name") # Read from the cache From 2d7302e2417fac18e9aaa25ea3598b8860cae856 Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:31:34 +0100 Subject: [PATCH 07/22] Update content/develop/connect/clients/client-side-caching.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/client-side-caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 20e290ad5c..185060cad9 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -15,7 +15,7 @@ title: Client-side caching introduction weight: 20 --- -*Client-side caching* is a technique to reduce network traffic between +*Client-side caching* reduces network traffic between a Redis client and the server. This generally gives better performance. See [Client-side caching compatibility with Redis Software and Redis Cloud]({{< relref "operate/rs/references/compatibility/client-side-caching" >}}) for details of the Redis versions that support CSC. From 13198e4e4b6cf0535b33d2f873c1e71cafcca3f5 Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:31:43 +0100 Subject: [PATCH 08/22] Update content/develop/connect/clients/client-side-caching.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/client-side-caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 185060cad9..6864aef62a 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -18,7 +18,7 @@ weight: 20 *Client-side caching* reduces network traffic between a Redis client and the server. This generally gives better performance. See [Client-side caching compatibility with Redis Software and Redis Cloud]({{< relref "operate/rs/references/compatibility/client-side-caching" >}}) -for details of the Redis versions that support CSC. +for details on Redis versions that support CSC. By default, an [application server](https://en.wikipedia.org/wiki/Application_server) (which sits between the user app and the database) contacts the From 2c541897664c614de3179955c76f595d6b880a0b Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:32:12 +0100 Subject: [PATCH 09/22] Update content/develop/connect/clients/client-side-caching.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/client-side-caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 6864aef62a..52df0e5a4d 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -29,7 +29,7 @@ through the application server to the database and back again: {{< image filename="images/csc/CSCNoCache.drawio.svg" >}} When you use CSC, the client library -maintains its own local cache of data items as it retrieves them +maintains a local cache of data items as it retrieves them from the database. When the same items are needed again, the client can satisfy the read requests from the cache instead of the database: From d8ad78ea763826428791fe81e95f75b7e9f184a7 Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:36:57 +0100 Subject: [PATCH 10/22] Update content/develop/connect/clients/python/redis-py.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/python/redis-py.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index e3a1fdd067..af1deee648 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -126,7 +126,7 @@ the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) for more information about how CSC works and how to use it effectively. -To enable CSC, you simply need to add some extra parameters when you connect +To enable CSC, add some extra parameters when you connect to the server: - `protocol`: (Required) You must pass a value of `3` here because From df0528a48e16034fb1aa3cf7b85a323d8c3c786c Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:37:42 +0100 Subject: [PATCH 11/22] Update content/develop/connect/clients/client-side-caching.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/client-side-caching.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index 52df0e5a4d..a74b4d759a 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -16,7 +16,7 @@ weight: 20 --- *Client-side caching* reduces network traffic between -a Redis client and the server. This generally gives better performance. +a Redis client and the server, which generally improves performance. See [Client-side caching compatibility with Redis Software and Redis Cloud]({{< relref "operate/rs/references/compatibility/client-side-caching" >}}) for details on Redis versions that support CSC. From df7c8a0895c61c1dd9bdd45195fa75ec514e2cc3 Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Mon, 23 Sep 2024 09:39:01 +0100 Subject: [PATCH 12/22] Update content/develop/connect/clients/java/jedis.md Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- content/develop/connect/clients/java/jedis.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index ad614ae1cd..051aeee0c1 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -203,7 +203,7 @@ the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) for more information about how CSC works and how to use it effectively. -To enable CSC, you simply need to specify the +To enable CSC, specify the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) protocol and pass a cache configuration object during the connection. From 8bca1bbe665a897431c5dd3b61588125ab94b060 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Mon, 23 Sep 2024 10:35:29 +0100 Subject: [PATCH 13/22] DOC-4037 removed CSC abbreviation --- .../connect/clients/client-side-caching.md | 22 +++++++++---------- content/develop/connect/clients/java/jedis.md | 10 ++++----- .../connect/clients/python/redis-py.md | 14 ++++++------ 3 files changed, 23 insertions(+), 23 deletions(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index a74b4d759a..adedcaca11 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -18,7 +18,7 @@ weight: 20 *Client-side caching* reduces network traffic between a Redis client and the server, which generally improves performance. See [Client-side caching compatibility with Redis Software and Redis Cloud]({{< relref "operate/rs/references/compatibility/client-side-caching" >}}) -for details on Redis versions that support CSC. +for details on Redis versions that support client-side caching. By default, an [application server](https://en.wikipedia.org/wiki/Application_server) (which sits between the user app and the database) contacts the @@ -28,7 +28,7 @@ through the application server to the database and back again: {{< image filename="images/csc/CSCNoCache.drawio.svg" >}} -When you use CSC, the client library +When you use client-side caching, the client library maintains a local cache of data items as it retrieves them from the database. When the same items are needed again, the client can satisfy the read requests from the cache instead of the database: @@ -41,7 +41,7 @@ the load on the database server, so you may be able to run it using fewer hardwa resources. As with other forms of [caching](https://en.wikipedia.org/wiki/Cache_(computing)), -CSC works well in the very common use case where a small subset of the data +client-side caching works well in the very common use case where a small subset of the data gets accessed much more frequently than the rest of the data (according to the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)). @@ -51,7 +51,7 @@ All caching systems must implement a scheme to update data in the cache when the corresponding data changes in the main database. Redis uses an approach called *tracking*. -When CSC is enabled, the Redis server remembers or *tracks* the set of keys +When client-side caching is enabled, the Redis server remembers or *tracks* the set of keys that each client connection has previously read. This includes cases where the client reads data directly, as with the [`GET`]({{< relref "/commands/get" >}}) command, and also where the server calculates values from the stored data, @@ -86,11 +86,11 @@ will use cached data, except for the following: [`FT.SEARCH`]({{< baseurl >}}/commands/ft.search). You can use the [`MONITOR`]({{< relref "/commands/monitor" >}}) command to -check the server's behavior when you are using CSC. Because `MONITOR` only +check the server's behavior when you are using client-side caching. Because `MONITOR` only reports activity from the server, you should find that the first cacheable access to a key causes a response from the server. However, subsequent accesses are satisfied by the cache, and so `MONITOR` should report no -server activity if CSC is working correctly. +server activity if client-side caching is working correctly. ## What data gets cached for a command? @@ -132,7 +132,7 @@ then cached separately. For example: ## Usage recommendations -Like any caching system, CSC has some limitations: +Like any caching system, client-side caching has some limitations: - The cache has only a limited amount of memory available. When the limit is reached, the client must *evict* potentially useful items from the @@ -140,7 +140,7 @@ Like any caching system, CSC has some limitations: - Cache misses, tracking, and invalidation messages always add a slight performance penalty. -Below are some guidelines to help you use CSC efficiently, within these +Below are some guidelines to help you use client-side caching efficiently, within these limitations: - **Use a separate connection for data that is not cache-friendly**: @@ -149,7 +149,7 @@ limitations: may also have data such as counters and scoreboards that receive frequent updates. In cases like this, the performance overhead of the invalidation messages can be greater than the savings made by caching. Avoid this problem - by using a separate connection *without* CSC for any data that is + by using a separate connection *without* client-side caching for any data that is not cache-friendly. - **Estimate how many items you can cache**: The client libraries let you specify the maximum number of items you want to hold in the cache. You @@ -166,8 +166,8 @@ limitations: ## Reference - The Redis server implements extra features for CSC that are not used by + The Redis server implements extra features for client-side caching that are not used by the main Redis clients, but may be useful for custom clients and other advanced applications. See [Client-side caching reference]({{< relref "/develop/reference/client-side-caching" >}}) - for a full technical guide to all the options available for CSC. + for a full technical guide to all the options available for client-side caching. diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index 051aeee0c1..dd5c74a0d2 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -196,21 +196,21 @@ public class Main { } ``` -## Connect using client-side caching (CSC) +## Connect using client-side caching *Client-side caching* is a technique to reduce network traffic between the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) -for more information about how CSC works and how to use it effectively. +for more information about how client-side caching works and how to use it effectively. -To enable CSC, specify the +To enable client-side caching, specify the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) protocol and pass a cache configuration object during the connection. -The example below shows the simplest CSC connection to the default host and port, +The example below shows the simplest client-side caching connection to the default host and port, `localhost:6379`. All of the connection variants described above accept these parameters, so you can -use CSC with a connection pool or a cluster connection in exactly the same way. +use client-side caching with a connection pool or a cluster connection in exactly the same way. ```java HostAndPort endpoint = new HostAndPort("localhost", 6379); diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index af1deee648..e76624153a 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -119,25 +119,25 @@ r.get('foo') ``` For more information, see [redis-py TLS examples](https://redis-py.readthedocs.io/en/stable/examples/ssl_connection_examples.html). -## Connect using client-side caching (CSC) +## Connect using client-side caching *Client-side caching* is a technique to reduce network traffic between the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) -for more information about how CSC works and how to use it effectively. +for more information about how client-side caching works and how to use it effectively. -To enable CSC, add some extra parameters when you connect +To enable client-side caching, add some extra parameters when you connect to the server: - `protocol`: (Required) You must pass a value of `3` here because - CSC requires the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) + client-side caching requires the [RESP3]({{< relref "/develop/reference/protocol-spec#resp-versions" >}}) protocol. -- `cache_config`: (Required) Pass `cache_config=CacheConfig()` here to enable CSC. +- `cache_config`: (Required) Pass `cache_config=CacheConfig()` here to enable client-side caching. -The example below shows the simplest CSC connection to the default host and port, +The example below shows the simplest client-side caching connection to the default host and port, `localhost:6379`. All of the connection variants described above accept these parameters, so you can -use CSC with a connection pool or a cluster connection in exactly the same way. +use client-side caching with a connection pool or a cluster connection in exactly the same way. ```python import redis From 56b14b5930eb6773da9a129e6f347b4957df9122 Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Thu, 26 Sep 2024 12:52:48 -0700 Subject: [PATCH 14/22] add link to rsyslog logging DOC-1595 add a link to rsyslog info from the log security page --- content/operate/rs/clusters/logging/log-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/operate/rs/clusters/logging/log-security.md b/content/operate/rs/clusters/logging/log-security.md index 7f17985d23..6ba7e715aa 100644 --- a/content/operate/rs/clusters/logging/log-security.md +++ b/content/operate/rs/clusters/logging/log-security.md @@ -15,7 +15,7 @@ Redis Enterprise comes with [a set of logs]({{< relref "/operate/rs/clusters/log Redis Enterprise sends logs to syslog by default. You can send these logs to a remote logging server by configuring syslog. -To do this, modify the syslog or rsyslog configuration on your operating system to send logs in the `$logdir` directory (`/var/opt/redislabs/log` in default installations) to a remote monitoring server of your choice. +To do this, modify the syslog or rsyslog configuration on your operating system to send logs in the `$logdir` directory (`/var/opt/redislabs/log` in default installations) to a remote monitoring server of your choice. See [rsyslog logging]({{< relref "/operate/rs/clusters/logging/rsyslog-logging/" >}}) for additional details. ## Log rotation From 7ebd937709215518c3a0ee7e75c3a027c4abe44a Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Thu, 26 Sep 2024 13:01:23 -0700 Subject: [PATCH 15/22] Update READWRITE index.md to fix typo #DOC-4215 fix typo in description & summary --- content/commands/readwrite/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/commands/readwrite/index.md b/content/commands/readwrite/index.md index 3aea260732..e8d9596a92 100644 --- a/content/commands/readwrite/index.md +++ b/content/commands/readwrite/index.md @@ -18,13 +18,13 @@ command_flags: - stale - fast complexity: O(1) -description: Enables read-write queries for a connection to a Reids Cluster replica +description: Enables read-write queries for a connection to a Redis Cluster replica node. group: cluster hidden: false linkTitle: READWRITE since: 3.0.0 -summary: Enables read-write queries for a connection to a Reids Cluster replica node. +summary: Enables read-write queries for a connection to a Redis Cluster replica node. syntax_fmt: READWRITE syntax_str: '' title: READWRITE From 6e1cce0998d72d4acf24d5b31db78d2285dd8a50 Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Thu, 26 Sep 2024 13:10:14 -0700 Subject: [PATCH 16/22] Update Uptrace _index.md #DOC-3920 remove duplicate description --- content/integrate/uptrace-with-redis-enterprise/_index.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/content/integrate/uptrace-with-redis-enterprise/_index.md b/content/integrate/uptrace-with-redis-enterprise/_index.md index b86422c4b1..6c2769f2d6 100644 --- a/content/integrate/uptrace-with-redis-enterprise/_index.md +++ b/content/integrate/uptrace-with-redis-enterprise/_index.md @@ -17,8 +17,6 @@ type: integration weight: 7 --- -To collect, view, and monitor metrics data from your databases and other cluster components, you can connect Uptrace to your Redis Enterprise cluster using OpenTelemetry Collector. - Uptrace is an [open source APM tool](https://uptrace.dev/get/open-source-apm.html) that supports distributed tracing, metrics, and logs. You can use it to monitor applications and set up automatic alerts to receive notifications. Uptrace uses OpenTelemetry to collect and export telemetry data from software applications such as Redis. OpenTelemetry is an open source observability framework that aims to provide a single standard for all types of observability signals such as traces, metrics, and logs. From 6abffb803d2cf58ed941544ab1d413801f1a7366 Mon Sep 17 00:00:00 2001 From: mich-elle-luna <153109578+mich-elle-luna@users.noreply.github.com> Date: Thu, 26 Sep 2024 13:23:49 -0700 Subject: [PATCH 17/22] Update JSON.STRLEN index.md DOC-2172 change array to string --- content/commands/json.strlen/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/commands/json.strlen/index.md b/content/commands/json.strlen/index.md index 01c7a30abd..8604e4da77 100644 --- a/content/commands/json.strlen/index.md +++ b/content/commands/json.strlen/index.md @@ -49,7 +49,7 @@ is JSONPath to specify. Default is root `$`, if not provided. Returns null if th ## Return -JSON.STRLEN returns by recursive descent an array of integer replies for each path, the array's length, or `nil`, if the matching JSON value is not a string. +JSON.STRLEN returns by recursive descent an array of integer replies for each path, the string's length, or `nil`, if the matching JSON value is not a string. For more information about replies, see [Redis serialization protocol specification]({{< relref "/develop/reference/protocol-spec" >}}). ## Examples From c2e6628c562c7eedf107e90e3bb3c2397435f336 Mon Sep 17 00:00:00 2001 From: andy-stark-redis <164213578+andy-stark-redis@users.noreply.github.com> Date: Fri, 27 Sep 2024 10:30:19 +0100 Subject: [PATCH 18/22] Apply suggestions from code review Co-authored-by: Kaitlyn Michael <76962844+kaitlynmichael@users.noreply.github.com> --- .../develop/connect/clients/client-side-caching.md | 14 +++++++------- content/develop/connect/clients/java/jedis.md | 4 ++-- content/develop/connect/clients/python/redis-py.md | 2 +- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index adedcaca11..fdeebfd717 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -36,13 +36,13 @@ can satisfy the read requests from the cache instead of the database: {{< image filename="images/csc/CSCWithCache.drawio.svg" >}} Accessing the cache is much faster than communicating with the database over the -network and it reduces network traffic. Also, this technique reduces -the load on the database server, so you may be able to run it using fewer hardware +network and it reduces network traffic. Client-side cacheing reduces +the load on the database server, so you may be able to run it using less hardware resources. As with other forms of [caching](https://en.wikipedia.org/wiki/Cache_(computing)), client-side caching works well in the very common use case where a small subset of the data -gets accessed much more frequently than the rest of the data (according +is accessed much more frequently than the rest of the data (according to the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle)). ## Updating the cache when the data changes @@ -77,7 +77,7 @@ will use cached data, except for the following: - Any commands for [probabilistic data types]({{< relref "/develop/data-types/probabilistic" >}}). These types are designed to be updated frequently, which means that caching - them gives little or no benefit. + has little or no benefit. - Non-deterministic commands such as [`HGETALL`]({{< relref "/commands/hgetall" >}}), [`HSCAN`]({{< relref "/commands/hscan" >}}), and [`ZRANDMEMBER`]({{< relref "/commands/zrandmember" >}}). By design, these commands @@ -87,7 +87,7 @@ will use cached data, except for the following: You can use the [`MONITOR`]({{< relref "/commands/monitor" >}}) command to check the server's behavior when you are using client-side caching. Because `MONITOR` only -reports activity from the server, you should find that the first cacheable +reports activity from the server, you should find the first cacheable access to a key causes a response from the server. However, subsequent accesses are satisfied by the cache, and so `MONITOR` should report no server activity if client-side caching is working correctly. @@ -146,7 +146,7 @@ limitations: - **Use a separate connection for data that is not cache-friendly**: Caching gives the most benefit for keys that are read frequently and updated infrequently. However, you - may also have data such as counters and scoreboards that receive frequent + may also have data, such as counters and scoreboards, that receives frequent updates. In cases like this, the performance overhead of the invalidation messages can be greater than the savings made by caching. Avoid this problem by using a separate connection *without* client-side caching for any data that is @@ -157,7 +157,7 @@ limitations: maximum desired size of the cache in memory by the average size of the items you want to store (use the [`MEMORY USAGE`]({{< relref "/commands/memory-usage" >}}) - command to get the memory footprint of a key). So, if you had + command to get the memory footprint of a key). For example, if you had 10MB (or 10485760 bytes) available for the cache, and the average size of an item was 80 bytes, you could fit approximately 10485760 / 80 = 131072 items in the cache. Monitor memory usage diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index dd5c74a0d2..2c2d561c06 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -247,7 +247,7 @@ you should see the following in the CLI among the output from `MONITOR`: 1723109720.270205 [...] "GET" "city" ``` -This shows that the server responds to both `get("city")` calls. +The server responds to both `get("city")` calls. If you run the code with `cacheConfig` added in again, you will see ``` @@ -255,7 +255,7 @@ If you run the code with `cacheConfig` added in again, you will see 1723110248.713607 [...] "GET" "city" ``` -This shows that the first `get("city")` call contacted the server but the second +The first `get("city")` call contacted the server, but the second call was satisfied by the cache. ### Removing items from the cache diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index e76624153a..32d0038f8f 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -166,7 +166,7 @@ the following in the CLI among the output from `MONITOR`: 1723109720.270205 [...] "GET" "city" ``` -This shows that the server responds to both `get("city")` calls. +The server responds to both `get("city")` calls. If you run the code again with `cache_config` uncommented, you will see ``` From 9c8695b01cda5d9bd61a6e52b4dd743b26271287 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Fri, 27 Sep 2024 11:32:12 +0100 Subject: [PATCH 19/22] DOC-4037 implemented PR feedback --- content/develop/connect/clients/client-side-caching.md | 4 ++-- content/develop/connect/clients/java/jedis.md | 2 +- content/develop/connect/clients/python/redis-py.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/content/develop/connect/clients/client-side-caching.md b/content/develop/connect/clients/client-side-caching.md index fdeebfd717..a0fb944a81 100644 --- a/content/develop/connect/clients/client-side-caching.md +++ b/content/develop/connect/clients/client-side-caching.md @@ -36,7 +36,7 @@ can satisfy the read requests from the cache instead of the database: {{< image filename="images/csc/CSCWithCache.drawio.svg" >}} Accessing the cache is much faster than communicating with the database over the -network and it reduces network traffic. Client-side cacheing reduces +network and it reduces network traffic. Client-side caching reduces the load on the database server, so you may be able to run it using less hardware resources. @@ -94,7 +94,7 @@ server activity if client-side caching is working correctly. ## What data gets cached for a command? -Broadly speaking, the data from the *specific response* to a command invocation +Broadly speaking, the data from the specific response to a command invocation gets cached after it is used for the first time. Subsets of that data or values calculated from it are retrieved from the server as usual and then cached separately. For example: diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index 2c2d561c06..36c74247f5 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -198,7 +198,7 @@ public class Main { ## Connect using client-side caching -*Client-side caching* is a technique to reduce network traffic between +Client-side caching is a technique to reduce network traffic between the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) for more information about how client-side caching works and how to use it effectively. diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index 32d0038f8f..e2a3864e80 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -121,7 +121,7 @@ For more information, see [redis-py TLS examples](https://redis-py.readthedocs.i ## Connect using client-side caching -*Client-side caching* is a technique to reduce network traffic between +Client-side caching is a technique to reduce network traffic between the client and server, resulting in better performance. See [Client-side caching introduction]({{< relref "/develop/connect/clients/client-side-caching" >}}) for more information about how client-side caching works and how to use it effectively. @@ -174,7 +174,7 @@ If you run the code again with `cache_config` uncommented, you will see 1723110248.713607 [...] "GET" "city" ``` -This shows that the first `get("city")` call contacted the server but the second +The first `get("city")` call contacted the server but the second call was satisfied by the cache. ### Removing items from the cache From 9cc46336d2037e934f88f44930782ab97efebfbd Mon Sep 17 00:00:00 2001 From: Igor Malinovskiy Date: Fri, 27 Sep 2024 16:22:34 +0200 Subject: [PATCH 20/22] Update Jedis version to 5.2.0 (#709) --- content/develop/connect/clients/java/jedis.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index b1465a9c1c..318093bed1 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -33,7 +33,7 @@ To include `Jedis` as a dependency in your application, edit the dependency file redis.clients jedis - 5.1.2 + 5.2.0 ``` @@ -45,7 +45,7 @@ To include `Jedis` as a dependency in your application, edit the dependency file } //... dependencies { - implementation 'redis.clients:jedis:5.1.2' + implementation 'redis.clients:jedis:5.2.0' //... } ``` From 84a24e2ce837805e2fe27da802a6ad1675d8e112 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Fri, 27 Sep 2024 15:53:14 +0100 Subject: [PATCH 21/22] DOC-4037 added note about minimum Jedis version --- content/develop/connect/clients/java/jedis.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index 36c74247f5..ad47f0d7db 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -212,6 +212,9 @@ The example below shows the simplest client-side caching connection to the defau All of the connection variants described above accept these parameters, so you can use client-side caching with a connection pool or a cluster connection in exactly the same way. +{{< note >}}Client-side caching requires Jedis v5.2.0 or later. +{{< /note >}} + ```java HostAndPort endpoint = new HostAndPort("localhost", 6379); From 322b3466980311933abe0c0ac69f1053c0311822 Mon Sep 17 00:00:00 2001 From: Andy Stark Date: Fri, 27 Sep 2024 16:30:32 +0100 Subject: [PATCH 22/22] DOC-4037 added note about minimum Redis version --- content/develop/connect/clients/java/jedis.md | 2 ++ content/develop/connect/clients/python/redis-py.md | 5 +++++ 2 files changed, 7 insertions(+) diff --git a/content/develop/connect/clients/java/jedis.md b/content/develop/connect/clients/java/jedis.md index ad47f0d7db..681b3be27d 100644 --- a/content/develop/connect/clients/java/jedis.md +++ b/content/develop/connect/clients/java/jedis.md @@ -213,6 +213,8 @@ All of the connection variants described above accept these parameters, so you c use client-side caching with a connection pool or a cluster connection in exactly the same way. {{< note >}}Client-side caching requires Jedis v5.2.0 or later. +To maximize compatibility with all Redis products, client-side caching +is supported by Redis v7.4 or later. {{< /note >}} ```java diff --git a/content/develop/connect/clients/python/redis-py.md b/content/develop/connect/clients/python/redis-py.md index e2a3864e80..dec87155d0 100644 --- a/content/develop/connect/clients/python/redis-py.md +++ b/content/develop/connect/clients/python/redis-py.md @@ -139,6 +139,11 @@ The example below shows the simplest client-side caching connection to the defau All of the connection variants described above accept these parameters, so you can use client-side caching with a connection pool or a cluster connection in exactly the same way. +{{< note >}}Client-side caching requires redis-py v5.1.0 or later. +To maximize compatibility with all Redis products, client-side caching +is supported by Redis v7.4 or later. +{{< /note >}} + ```python import redis from redis.cache import CacheConfig