1

We notice that the .NET HttpClient takes atleast ~20 seconds to fail while trying to connect to an endpoint that is invalid. I was wondering if there is a way to make it fail faster, because our back-end services could be moving to different nodes based on criteria such as load etc. We have a mechanism to retrieve the new location of these services, if there is a communication failure to a particular service. But, since the HttpClient failure time is ~20s, as a result response time for the client request is degrading.

I was looking at the documentation and notice that the HttpClient timeout may take atleast 15s due to the DNS resolution. There was similar post about this here,

HttpClient - how to figure out if server is down faster?

But, all our endpoints have IP addresses in their host that should be preventing the DNS look-up according to this post here,

How to prevent DNS lookup when fetching by using HttpClient

internal static bool TryInternalResolve(string hostName, out IPHostEntry result)
{
    if (Logging.On)
        Logging.Enter(Logging.Sockets, "DNS", "TryInternalResolve", hostName);

    if (string.IsNullOrEmpty(hostName) || hostName.Length > MaxHostName)
    {
        result = null;
        return false;
    }

    IPAddress address;
    if (IPAddress.TryParse(hostName, out address))
    {
        GlobalLog.Print("Dns::InternalResolveFast() returned address:" + address.ToString());
        result = GetUnresolveAnswer(address); // Do not do reverse lookups on IPAddresses.
        return true;
    }
}

https://referencesource.microsoft.com/#System/net/System/Net/DNS.cs,e177fd4099d6a754,references

We are still trying to capture this behavior in a local environment with fiddler or netmon.

Where could the httpclient be spending bulk of its time to fail? Are there any master settings that can prevent this time delay on failure?

Julia Schatzmann
  • 5
  • 2
iambatman
  • 107
  • 1
  • 2
  • 16
  • 1
    Have you tried to lower the HttpClient's timeout? – Gusman Feb 12 '18 at 20:03
  • We would rather not set a timeout on the HttpClient itself as we have no idea at this point how long the operation will take at the back-end service. If the connection was indeed successful, there is nothing stopping us from waiting until the operation completes. But, we do have other mechanism to handle timeouts or cancel the user operation. – iambatman Feb 12 '18 at 21:31
  • Then I don't think it's possible with HttpClient to reduce the time. If you handle manually the requests with HttpWebRequest you have separated timeouts, one for read/write data, other for 100-Continue and other for response retrieval, in your case you can reduce the response retrieval timeout and leave untouched the rest. – Gusman Feb 12 '18 at 22:23
  • If you mechanism to retrieve the new location of these services, why are you even trying the old one? how often do your services change location? – Dusan Bajic Feb 13 '18 at 08:05
  • We do not want to always retrieve new location of these services everytime we communicate. That is an expensive process. So, we locally cache the info and only update them on failure to connect. The services changes location in a non-deterministic manner. – iambatman Feb 13 '18 at 18:17

0 Answers0