Skip to content

Research and add defaults to HTTP resilience content #41611

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 2, 2024
Merged

Research and add defaults to HTTP resilience content #41611

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
62e6449
Researched and add defaults to HTTP resilience content
IEvangelist Jul 1, 2024
ff1e98d
Apply suggestions from code review
IEvangelist Jul 2, 2024
1816585
Address peer feedback and add HTTP status code and exs
IEvangelist Jul 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 28 additions & 15 deletions docs/core/resilience/http-resilience.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ title: "Build resilient HTTP apps: Key development patterns"
description: Learn how to build resilient HTTP apps using the Microsoft.Extensions.Http.Resilience NuGet package.
author: IEvangelist
ms.author: dapine
ms.date: 10/20/2023
ms.date: 07/01/2024
---

# Build resilient HTTP apps: Key development patterns
Expand Down Expand Up @@ -81,13 +81,26 @@ The preceding code adds the standard resilience handler to the <xref:System.Net.

The default configuration chains five resilience strategies in the following order (from the outermost to the innermost):

| Order | Strategy | Description |
|--:|--|--|
| **1** | Rate limiter | The rate limiter pipeline limits the maximum number of concurrent requests being sent to the dependency. |
| **2** | Total request timeout | The total request timeout pipeline applies an overall timeout to the execution, ensuring that the request, including retry attempts, doesn't exceed the configured limit. |
| **3** | Retry | The retry pipeline retries the request in case the dependency is slow or returns a transient error. |
| **4** | Circuit breaker | The circuit breaker blocks the execution if too many direct failures or timeouts are detected. |
| **5** | Attempt timeout | The attempt timeout pipeline limits each request attempt duration and throws if it's exceeded. |
| Order | Strategy | Description | Defaults |
|--:|--|--|--|
| **1** | Rate limiter | The rate limiter pipeline limits the maximum number of concurrent requests being sent to the dependency. | Queue: `0`<br>Permit: `1_000` |
| **2** | Total timeout | The total request timeout pipeline applies an overall timeout to the execution, ensuring that the request, including retry attempts, doesn't exceed the configured limit. | Total timeout: 30s |
| **3** | Retry | The retry pipeline retries the request in case the dependency is slow or returns a transient error. | Max retries: `3`<br>Backoff: `Exponential`<br>Use jitter: `true`<br>Delay:2s |
| **4** | Circuit breaker | The circuit breaker blocks the execution if too many direct failures or timeouts are detected. | Failure ratio: 10%<br>Min throughput: `100`<br>Sampling duration: 30s<br>Break duration: 5s |
| **5** | Attempt timeout | The attempt timeout pipeline limits each request attempt duration and throws if it's exceeded. | Attempt timeout: 10s |

#### Retries and circuit breakers

The retry and circuit breaker strategies both handle a set of specific HTTP status codes and exceptions. Consider the following HTTP status codes:

- HTTP 500 and above (Server errors)
- HTTP 408 (Request timeout)
- HTTP 429 (Too many requests)

Additionally, these strategies handle the following exceptions:

- `HttpRequestException`
- `TimeoutRejectedException`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do the same thing for hedging? Just add circuit breaker exception too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow. So, the Hedging handler employs what defaults?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hedging has different ShouldHandle predicate compared to standard resilience:

https://github.com/dotnet/extensions/blob/b60b982e9b5bc6273aaed1f70f9002e381aae97a/src/Libraries/Microsoft.Extensions.Http.Resilience/Hedging/HttpClientHedgingResiliencePredicates.cs#L53

Maybe just note that status codes/exceptions are the same as compared to standard resilience, but hedging strategy also handles BrokenCircuitException.


## Add standard hedging handler

Expand All @@ -108,13 +121,13 @@ The standard hedging uses a pool of circuit breakers to ensure that unhealthy en

The preceding code adds the standard hedging handler to the <xref:Microsoft.Extensions.DependencyInjection.IHttpClientBuilder>. The default configuration chains five resilience strategies in the following order (from the outermost to the innermost):

| Order | Strategy | Description |
|--:|--|--|
| **1** | Total request timeout | The total request timeout pipeline applies an overall timeout to the execution, ensuring that the request, including hedging attempts, doesn't exceed the configured limit. |
| **2** | Hedging | The hedging strategy executes the requests against multiple endpoints in case the dependency is slow or returns a transient error. Routing is options, by default it just hedges the URL provided by the original <xref:System.Net.Http.HttpRequestMessage>. |
| **3** | Rate limiter (per endpoint) | The rate limiter pipeline limits the maximum number of concurrent requests being sent to the dependency. |
| **4** | Circuit breaker (per endpoint) | The circuit breaker blocks the execution if too many direct failures or timeouts are detected. |
| **5** | Attempt timeout (per endpoint) | The attempt timeout pipeline limits each request attempt duration and throws if it's exceeded. |
| Order | Strategy | Description | Defaults |
|--:|--|--|--|
| **1** | Total request timeout | The total request timeout pipeline applies an overall timeout to the execution, ensuring that the request, including hedging attempts, doesn't exceed the configured limit. | Total timeout: 30s |
| **2** | Hedging | The hedging strategy executes the requests against multiple endpoints in case the dependency is slow or returns a transient error. Routing is options, by default it just hedges the URL provided by the original <xref:System.Net.Http.HttpRequestMessage>. | Min attempts: `1`<br>Max attempts: `10`<br>Delay: 2s |
| **3** | Rate limiter (per endpoint) | The rate limiter pipeline limits the maximum number of concurrent requests being sent to the dependency. | Queue: `0`<br>Permit: `1_000` |
| **4** | Circuit breaker (per endpoint) | The circuit breaker blocks the execution if too many direct failures or timeouts are detected. | Failure ratio: 10%<br>Min throughput: `100`<br>Sampling duration: 30s<br>Break duration: 5s |
| **5** | Attempt timeout (per endpoint) | The attempt timeout pipeline limits each request attempt duration and throws if it's exceeded. | Timeout: 10s |

### Customize hedging handler route selection

Expand Down