@@ -25,7 +25,6 @@ for a recommendation. Use the checklist icons to record your
25
25
progress in implementing the recommendations.
26
26
27
27
{{< checklist "pyprodlist" >}}
28
- {{< checklist-item "#connection-pooling" >}}Connection pooling{{< /checklist-item >}}
29
28
{{< checklist-item "#client-side-caching" >}}Client-side caching{{< /checklist-item >}}
30
29
{{< checklist-item "#retries" >}}Retries{{< /checklist-item >}}
31
30
{{< checklist-item "#health-checks" >}}Health checks{{< /checklist-item >}}
@@ -37,19 +36,6 @@ progress in implementing the recommendations.
37
36
The sections below offer recommendations for your production environment. Some
38
37
of them may not apply to your particular use case.
39
38
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
-
53
39
### Client-side caching
54
40
55
41
[ Client-side caching] ({{< relref "/develop/clients/client-side-caching" >}})
@@ -67,58 +53,65 @@ such as temporary network outages or timeouts. When this happens,
67
53
the operation will generally succeed after a few attempts, despite
68
54
failing the first time.
69
55
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
75
60
[ 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:
77
70
78
71
``` py
79
72
from redis.backoff import ExponentialBackoff
80
73
from redis.retry import Retry
81
74
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 )
91
77
92
- ``` py
93
- # Retry only on timeout
94
78
r = Redis(
95
79
retry = retry,
96
- retry_on_timeout = True
97
80
.
98
81
.
99
82
)
83
+ ```
100
84
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.
102
101
from redis.exceptions import (
103
102
BusyLoadingError,
104
- ConnectionError ,
105
- TimeoutError
106
103
)
107
104
.
108
105
.
109
106
110
107
r = Redis(
111
108
retry = retry,
112
- retry_on_error = [BusyLoadingError, ConnectionError , TimeoutError ],
109
+ retry_on_error = [BusyLoadingError],
113
110
.
114
111
.
115
112
)
116
113
```
117
114
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
-
122
115
For a connection to a Redis cluster, you can specify a ` retry ` instance,
123
116
but the list of exceptions is not configurable and is always set
124
117
to ` TimeoutError ` , ` ConnectionError ` , and ` ClusterDownError ` .
@@ -146,9 +139,9 @@ r = Redis(
146
139
```
147
140
148
141
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 .
152
145
153
146
### Exception handling
154
147
0 commit comments