You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: timeouts-retries/README.md
+52-20Lines changed: 52 additions & 20 deletions
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,16 @@
1
1
# Timeouts and Retries
2
2
3
+
Envoy allows retries to be configured both in the [route configuration](https://www.envoyproxy.io/docs/envoy/v1.5.0/api-v2/rds.proto#envoy-api-msg-routeaction-retrypolicy) as well as for specific requests via [request headers](https://www.envoyproxy.io/docs/envoy/v1.5.0/configuration/http_filters/router_filter#config-http-filters-router-headers). The demo here shows how to configure request timeouts and retries using the envoy route configuration.
4
+
3
5
## Demo Overview
4
6
5
7

6
8
7
-
Front-proxy configurations are the same as the ones in [HTTP Routing: Simple Match Routing](../httproute-simple-match). Differences from [HTTP Routing: Simple Match Routing](../httproute-simple-match) are the following 2 additional behaviors:
9
+
Frontproxy configurations in this demo are the same as the ones in [HTTP Routing: Simple Match Routing](../httproute-simple-match) except the following two additional behaviors:
8
10
-`Timeouts` (5 seconds) for the request to `service_blue`
9
11
-`Retries` that Envoy will attempt to do if `service_red` responds with any 5xx response code
10
12
11
-
For Service Containers, `delay` fault injection and `abort` fault injection are configured in `service_blue` and `service_red` respectively (which are the same configuration as the ones in [Fault Injection Demo](../fault-injection))
13
+
For Service Containers in the demo, `delay` fault injection and `abort` fault injection are configured in `service_blue` and `service_red` respectively (which are the same configuration as the ones in [Fault Injection Demo](../fault-injection))
12
14
13
15
Key definition - `virtual_hosts` in [front-envoy.yaml](front-envoy.yaml)
14
16
```yaml
@@ -31,12 +33,15 @@ Key definition - `virtual_hosts` in [front-envoy.yaml](front-envoy.yaml)
31
33
route:
32
34
cluster: service_red
33
35
retry_policy:
34
-
retry_on: "5xx"
35
-
num_retries: 3
36
-
per_try_timeout: 5s
36
+
retry_on: "5xx"
37
+
num_retries: 3
38
+
per_try_timeout: 5s
37
39
```
38
-
> - `timeout`: (Duration) Specifies the timeout for the route. If not specified, the default is 15s. For more detail, see `timeout` section in [RouteAction](https://www.envoyproxy.io/docs/envoy/v1.5.0/api-v2/rds.proto#routeaction)
39
-
> - `retry_policy` indicates the retry policy for all routes in this virtual host. For more detail on retry_policy, see [route.RetryPolicy](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route.proto.html#envoy-api-msg-route-retrypolicy)
40
+
> - `timeout`: (Duration) Specifies the timeout for the route. If not specified, the default is 15s. For more detail, see`timeout`section in [RouteAction](https://www.envoyproxy.io/docs/envoy/v1.5.0/api-v2/rds.proto#routeaction)
41
+
> - `retry_policy` indicates the retry policy for all routes in this virtual host. For more detail on retry_policy, see [route.RetryPolicy](https://www.envoyproxy.io/docs/envoy/v1.5.0/api-v2/rds.proto#envoy-api-msg-routeaction-retrypolicy)
42
+
> - `retry_on`: it's retry condition by which the Envoy can retry on different types of conditions depending on application requirements. For example, network failure, all 5xx response codes, idempotent 4xx response codes, etc.
43
+
> - `num_retires`: Maximum number of retries. Envoy will continue to retry any number of times. An exponential backoff algorithm is used between each retry.
44
+
40
45
41
46
## Getting Started
42
47
```sh
@@ -50,24 +55,24 @@ cd envoy-proxy-demos/timeouts-retries
Access serivce_blue and check if 50% of requests to service_blue are timeout error (over 5 seconds timeout error with 504 status code). The following helper command allow you to send requests repeatedly (For example, send 10 requests to http://localhost:8000/service/blue).
Sending GET request: http://localhost:8000/service/blue
82
87
504
@@ -93,13 +98,13 @@ Sending GET request: http://localhost:8000/service/blue
93
98
Access serivce_blue and check if green background page is displayed. It is expected that nothting special will occur
94
99
95
100
```sh
96
-
$ curl -s http://localhost:8000/service/green
101
+
curl -s http://localhost:8000/service/green
97
102
```
98
103
99
104
Access serivce_red and check if most of requests to service_red are ok (200 status code), but seldomly you'll get abort error (503 status code). To explain what happens behind the senene, 50% of requests to `service_red` will be aborted with 503 error code due to the fault injection config in service_red, however the request will be recovered by the front proxy's retry mechanism, which is why most of the requests to service_red tuned out to be ok (200 status code). The following helper command allow you to send requests repeatedly (For example, send 10 requests to http://localhost:8000/service/blue)
Sending GET request: http://localhost:8000/service/red
105
110
200
@@ -108,26 +113,53 @@ Sending GET request: http://localhost:8000/service/red
108
113
Sending GET request: http://localhost:8000/service/red
109
114
200
110
115
Sending GET request: http://localhost:8000/service/red
111
-
200
116
+
503
112
117
Sending GET request: http://localhost:8000/service/red
113
118
200
114
119
Sending GET request: http://localhost:8000/service/red
115
120
200
116
121
Sending GET request: http://localhost:8000/service/red
117
122
200
118
123
Sending GET request: http://localhost:8000/service/red
119
-
503
124
+
200
120
125
Sending GET request: http://localhost:8000/service/red
121
126
200
122
127
Sending GET request: http://localhost:8000/service/red
123
128
200
124
129
```
125
130
131
+
The example run above shows 503 status code one time out of 10 requests, however as explained above this isn't what actually occured. Let's see what it was like with `docker-compose logs`:
It shows `service_red` was be aborted with 503 error code, and that requests from the front proxy was retried and was recovered if it was within `3` retries, the value of `num_retries`.
0 commit comments