HttpClient Polly 超时策略

Question

The get request is waiting longer than the timeoutPolicy to timeout.

• Does anyone have any idea why this is happening?
• Why does the request not timeout at 30ms?

var timeoutPolicy = Policy.TimeoutAsync(TimeSpan.FromMilliseconds(30), TimeoutStrategy.Optimistic);
var watch = new Stopwatch();
try
{
    watch.Start();
    var httpResponse = await timeoutPolicy.ExecuteAsync(
        async ct => await httpClient.SendAsync(new HttpRequestMessage(HttpMethod.Get, "https://google.com"), ct),
        CancellationToken.None
    );
    watch.Stop();
    Console.WriteLine("request took " + watch.ElapsedMilliseconds);
}
catch (Exception e)
{
    watch.Stop();
    Console.WriteLine("timeout took " + watch.ElapsedMilliseconds);
    Console.WriteLine(e.Message);
}

Answer 1

I think I've played around with it enough that I know what's going on, So I feel confident that I can now answer the question.

When you invoke the async task with TimeoutStrategy.Optimistic Polly strategy, you are passing in a CancellationToken and essentially trusting that the CancellationToken will be invoked to end the task in a timeout scenario.

Unlike the behavior with the TimeoutStrategy.Pesimistic strategy which is designed to be able to terminate a syncronous task which does not callback via the CancellationToken .

While your main execution thread is not blocked by an asyncronous task running on another thread, it's important to remember that the task is indeed able to block it's own thread.

For example, If an async task were to call Thread.Sleep(1000) then it's thread would be blocked for a second. Which in turn means that the CancellationToken cannot be invoked for the duration of the block.

In this scenario I believe that long running operations such as looking up the DNS record for a hostname the first time, or any other blocking operation is occurring which is essentially blocking the thread for 90ms.

As such, even though the task knows that it needs to be aborted at the 30ms mark, it need to wait for the thread to be available before it can actually invoke the cancellation, which doesn't occur until about 90ms or thereabouts.

This delay in returning a timeout only seems to occur the first time for each domain resolution, so I presume this is related to nameserver caching and DNS resolution as subsequent calls seem to honor the timeout more efficiently. Although asserting any direct root cause is largely speculation.