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,
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