Slow Proxy Discovery

The initial connection to a web service is always going to take some time to complete. If you've been reading for a while, then you know that calling Open on the proxy client before the first call is one way to get the initial connection expense out of the way. Otherwise, the initial connection happens when the first call is made. Successive calls tend to be faster as you've completed the initial work and warmed up all of the relevant network resources.

However, the initial call sometimes takes far longer than you'd expect even though you know there is some additional work going on. In these cases, there is a noticeable delay, sometimes on the order of five, ten, or even twenty seconds. This much longer delay is typically caused by a network resource being unavailable. For example,

  • You may be trying to resolve a host name and your DNS server isn't working.
  • You may be trying to contact a domain controller that isn't present.
  • You may be retrying authorization requests with bad credentials.
  • You may have misconfigured proxy settings on your system.

The last one is my favorite because it is such an unexpected way to be tripped up. Automatic proxy detection is a scriptable way to find proxy servers with little or no configuration on the user's part. It uses a variety of search mechanisms, such as DHCP, DNS, and the registry, in a predefined order to locate a proxy configuration script. Since automatic proxy detection has little interaction with the user and little visible effect, it is easy to forget that it exists until it fails entirely.

There is no foolproof way to diagnose issues with excessively long first call times. Often, you need to do some data gathering first to figure out what network resource is failing to respond and why someone is attempting to access that resource. A good way to get started with this investigation is to simply run the client under a debugger and collect a stack trace during the first call. Since the vast majority of the time is spent sitting around waiting for the offending method to complete, you can frequently find out who is causing the problem rather quickly although you still have to figure out how to fix it.

Next time: Irrevocable Certificates

Comments (3)

  1. Services have a built-in defense mechanism, called throttles, to prevent them from taking over too much

  2. LA.NET [EN] says:

    Today I was able to get back to my previous WCF client problem that I had described here . After looking

  3. ASPInsiders says:

    Today I was able to get back to my previous WCF client problem that I had described here . After looking

Skip to main content