DOC-4340 added conn/mux page diagrams and links

Author: andy-stark-redis

content/develop/connect/clients/dotnet.md

@@ -84,20 +84,6 @@ IJsonCommands json = db.JSON();
 ITimeSeriesCommands ts = db.TS();
 ```
 
-### Multiplexing
-
-Although example code typically works with a single connection,
-real-world code often uses multiple connections at the same time.
-Opening and closing connections repeatedly is inefficient, so it is best
-to manage open connections carefully to avoid this.
-
-Several other
-Redis client libraries use *connection pools* to reuse a set of open
-connections efficiently. NRedisStack uses a different approach called
-*multiplexing*, which sends all client commands and responses over a
-single connection. NRedisStack manages multiplexing for you automatically.
-This gives high performance without requiring any extra coding.
-
 ## Connect to a Redis cluster
 
 To connect to a Redis cluster, you just need to specify one or all cluster endpoints in the client configuration:
@@ -183,6 +169,23 @@ conn.StringSet("foo", "bar");
 Console.WriteLine(conn.StringGet("foo"));   
 ```
 
+## Multiplexing
+
+Although example code typically works with a single connection,
+real-world code often uses multiple connections at the same time.
+Opening and closing connections repeatedly is inefficient, so it is best
+to manage open connections carefully to avoid this.
+
+Several other
+Redis client libraries use *connection pools* to reuse a set of open
+connections efficiently. NRedisStack uses a different approach called
+*multiplexing*, which sends all client commands and responses over a
+single connection. NRedisStack manages multiplexing for you automatically.
+This gives high performance without requiring any extra coding.
+See
+[Connection pools and multiplexing]({{< relref "/develop/connect/clients/pools-and-muxing" >}})
+for more information.
+
 ## Example: Indexing and querying JSON documents
 
 This example shows how to convert Redis search results to JSON format using `NRedisStack`.

content/develop/connect/clients/java/jedis.md

@@ -312,6 +312,9 @@ efficiently. When you open a connection from a pool, the pool allocates you
 one of its open connections. When you subsequently close the same connection,
 it is not actually closed but simply returned to the pool for reuse.
 This avoids the overhead of repeated connecting and disconnecting.
+See
+[Connection pools and multiplexing]({{< relref "/develop/connect/clients/pools-and-muxing" >}})
+for more information.
 
 Use the following code to connect with a connection pool:
 

content/develop/connect/clients/java/lettuce.md

@@ -234,6 +234,9 @@ try (RedisClient client = RedisClient.create(redisURI)) {
 
 A typical approach with Lettuce is to create a single `RedisClient` instance and reuse it to establish connections to your Redis server(s).
 These connections are multiplexed; that is, multiple commands can be run concurrently over a single or a small set of connections, making explicit pooling less practical.
+See
+[Connection pools and multiplexing]({{< relref "/develop/connect/clients/pools-and-muxing" >}})
+for more information.
 
 Lettuce provides pool config to be used with Lettuce asynchronous connection methods.
 

content/develop/connect/clients/pools-and-muxing.md

@@ -38,14 +38,24 @@ supports both approaches.
 ## Connection pooling
 
 When you initialize a connection pool, the client opens a small number
-of connections and adds them to the pool. Each time you "open" a connection
+of connections and adds them to the pool.
+
+{{< image filename="/images/dev/connect/pool-and-mux/ConnPoolInit.drawio.svg" >}}
+
+Each time you "open" a connection
 from the pool, the client actually justs returns one of these existing
-connections and notes the fact that it is in use. When you later "close"
+connections and notes the fact that it is in use.
+
+{{< image filename="/images/dev/connect/pool-and-mux/ConnPoolInUse.drawio.svg" >}}
+
+When you later "close"
 the connection, the client puts it back into the pool of available
 connections without actually closing it.
 
+{{< image filename="/images/dev/connect/pool-and-mux/ConnPoolDiscon.drawio.svg" >}}
+
 If all connections in the pool are in use but the app needs more then
-the client can simply add new ones as necessary. In this way, the client
+the client can simply open new ones as necessary. In this way, the client
 eventually finds the right number of connections to satisfy your
 app's demands.
 
@@ -56,8 +66,10 @@ single connection open and uses it for all traffic between the
 client and the server. The "connections" returned to your code are
 simply to identify where to send the response data from your commands.
 
-When the multiplexer receives several commands in quick succession, it
-can often combine them into a
+{{< image filename="/images/dev/connect/pool-and-mux/ConnMux.drawio.svg" >}}
+
+Note that it is not a problem if the multiplexer receives several commands close
+together in time. When this happens, the multiplexer can often combine the commands into a
 [pipeline]({{< relref "/develop/use/pipelining" >}}), which
 improves efficiency even more.
 

content/develop/connect/clients/python/redis-py.md

@@ -241,6 +241,9 @@ efficiently. When you open a connection from a pool, the pool allocates you
 one of its open connections. When you subsequently close the same connection,
 it is not actually closed but simply returned to the pool for reuse.
 This avoids the overhead of repeated connecting and disconnecting.
+See
+[Connection pools and multiplexing]({{< relref "/develop/connect/clients/pools-and-muxing" >}})
+for more information.
 
 Use the following code to connect with a connection pool: