Skip to content

Commit 24c9f39

Browse files
DOC-5065 implemented feedback
1 parent 7349e95 commit 24c9f39

File tree

1 file changed

+36
-43
lines changed

1 file changed

+36
-43
lines changed

content/develop/clients/redis-py/produsage.md

Lines changed: 36 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,6 @@ for a recommendation. Use the checklist icons to record your
2525
progress in implementing the recommendations.
2626

2727
{{< checklist "pyprodlist" >}}
28-
{{< checklist-item "#connection-pooling" >}}Connection pooling{{< /checklist-item >}}
2928
{{< checklist-item "#client-side-caching" >}}Client-side caching{{< /checklist-item >}}
3029
{{< checklist-item "#retries" >}}Retries{{< /checklist-item >}}
3130
{{< checklist-item "#health-checks" >}}Health checks{{< /checklist-item >}}
@@ -37,19 +36,6 @@ progress in implementing the recommendations.
3736
The sections below offer recommendations for your production environment. Some
3837
of them may not apply to your particular use case.
3938

40-
### Connection pooling
41-
42-
Example code often opens a connection at the start, demonstrates a feature,
43-
and then closes the connection at the end. However, production code
44-
typically uses connections many times intermittently. Repeatedly opening
45-
and closing connections has a performance overhead.
46-
47-
Use [connection pooling]({{< relref "/develop/clients/pools-and-muxing" >}})
48-
to avoid the overhead of opening and closing connections without having to
49-
write your own code to cache and reuse open connections. See
50-
[Connect with a connection pool]({{< relref "/develop/clients/redis-py/connect#connect-with-a-connection-pool" >}})
51-
to learn how to use this technique with `redis-py`.
52-
5339
### Client-side caching
5440

5541
[Client-side caching]({{< relref "/develop/clients/client-side-caching" >}})
@@ -67,58 +53,65 @@ such as temporary network outages or timeouts. When this happens,
6753
the operation will generally succeed after a few attempts, despite
6854
failing the first time.
6955

70-
You can configure `redis-py` to retry commands automatically when
71-
errors occur. Use an instance of the `Retry` class to
72-
specify the number of times to retry after a failure. You can also
73-
specify a backoff strategy to control the time gap between attempts.
74-
For example, the following code creates a `Retry` with
56+
`redis-py` can retry commands automatically when
57+
errors occur. From version 6.0.0 onwards, the default behavior is to
58+
attempt a failed command three times.
59+
The timing between successive attempts is calculated using
7560
[exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)
76-
that will make three repeated attempts after a failure:
61+
with some random "jitter" added to avoid two or more connections retrying
62+
commands in sync with each other.
63+
64+
You can override the default behavior using an instance of the `Retry` class to
65+
specify the number of times to retry after a failure along with your
66+
own choice of backoff strategy.
67+
Pass the `Retry` object in the `retry` parameter when you connect.
68+
For example, the connection in the code below uses an exponential backoff strategy
69+
(without jitter) that will make eight repeated attempts after a failure:
7770

7871
```py
7972
from redis.backoff import ExponentialBackoff
8073
from redis.retry import Retry
8174

82-
# Run 3 retries with exponential backoff strategy.
83-
retry = Retry(ExponentialBackoff(), 3)
84-
```
85-
86-
Pass the `Retry` instance in the `retry` parameter when you connect
87-
to Redis. When you are connecting to a standalone Redis server,
88-
you can also set the `retry_on_timeout` parameter to `True`
89-
(to retry only after timeout errors), or pass a list of exception
90-
types in the `retry_on_error` parameter.
75+
# Run 8 retries with exponential backoff strategy.
76+
retry = Retry(ExponentialBackoff(), 8)
9177

92-
```py
93-
# Retry only on timeout
9478
r = Redis(
9579
retry=retry,
96-
retry_on_timeout=True
9780
.
9881
.
9982
)
83+
```
10084

101-
# Retry on any of a specified list of command exceptions.
85+
A retry is triggered when a command throws any exception
86+
listed in the `supported_errors` attribute of the `Retry` class.
87+
By default, the list only includes `ConnectionError` and `TimeoutError`,
88+
but you can set your own choice of exceptions when you create the
89+
instance:
90+
91+
```py
92+
# Only retry after a `TimeoutError`.
93+
retry = Retry(ExponentialBackoff(), 3, supported_errors=(TimeoutError,))
94+
```
95+
96+
You can also add extra exceptions to the default list using the `retry_on_error`
97+
parameter when you connect:
98+
99+
```py
100+
# Add `BusyLoadingError` to the default list of exceptions.
102101
from redis.exceptions import (
103102
BusyLoadingError,
104-
ConnectionError,
105-
TimeoutError
106103
)
107104
.
108105
.
109106

110107
r = Redis(
111108
retry=retry,
112-
retry_on_error=[BusyLoadingError, ConnectionError, TimeoutError],
109+
retry_on_error=[BusyLoadingError],
113110
.
114111
.
115112
)
116113
```
117114

118-
If you specify either `retry_on_timeout` or `retry_on_error` without
119-
a `retry` parameter, the default is to retry once immediately with no
120-
backoff.
121-
122115
For a connection to a Redis cluster, you can specify a `retry` instance,
123116
but the list of exceptions is not configurable and is always set
124117
to `TimeoutError`, `ConnectionError`, and `ClusterDownError`.
@@ -146,9 +139,9 @@ r = Redis(
146139
```
147140

148141
Health checks help to detect problems as soon as possible without
149-
waiting for a user to report them. If a `ConnectionError` or `TimeoutError`
150-
occurs for the health check itself, a second attempt will be made before
151-
reporting failure.
142+
waiting for a user to report them. Note that health checks, like
143+
other commands, will be [retried](#retries) using the strategy
144+
that you specified for the connection.
152145

153146
### Exception handling
154147

0 commit comments

Comments
 (0)