First call to a .net webservice is slow

问题:

I'm calling a .net webservice from my .net winforms app, both in framework 4.0. During the execution of the program, the first time the webservice has a method called, the call takes ~10-12 seconds. Subsequent calls take ~1-2 seconds. Subsequent calls, even when the web reference instance is recreated, are still ~1-2 seconds. When the winforms app is restarted, the first call delay occurs again, but subsequent calls are responsive.

The instance of the web reference is being created prior to the call occuring, and is not part of the delay.

XmlSerializers for the winforms app are being generated (and used, as far as I know, but I'm not sure how to verify this).

The delay is not occuring because of a first-run compilation on the webservice side. This is a production webservice that is being used throughout the day, and its apppool is remaining in memory. As far as I can see, the delay is occurring either on the client side, or between the client and the server for that first call, but not subsequent calls.

Not sure what to check next. Any ideas?

回答1:

As spender had indicated, the issue had to do with the proxy detection. Turning that off in Internet Explorer solved the problem, but was not feasible to do in my situation.

Instead, there is a workaround to bypass the use of the default proxy, and therefore the automatic detection.

Adding these entries to the app.config allows certain URLs to bypass the proxy:

<configuration>
    <system.net>
        <defaultProxy>
            <bypasslist>
                <add address="server/domain name" />
            </bypasslist>
        </defaultProxy>
    </system.net>
</configuration>

More information can be found here: <defaultProxy Element> on MSDN

回答2:

try setting the proxy to an empty WebProxy, ie:

request.Proxy = new WebProxy(); 

or you can override the proxy settings in the .Config file for your application using the defaultProxy key in the system.net section. The following disables automatic Proxy detection:

<configuration >
  <system.net>
    <defaultProxy>
      <proxy bypassonlocal="true" usesystemdefault="false" />
    </defaultProxy>
</system.net>
</configuration>

http://weblog.west-wind.com/posts/2005/Dec/14/Slow-Http-client-calls-from-ASPNET-20-Make-sure-you-check-your-Proxy-Settings

回答3:

I have suffered this problem many times - man I hate it!!! lol Whilst I have never conclusively solved it, you could try a couple of things. Firstly, make a call to the web service during start up and get the 'pain' out of the way first! Secondly, try messing with the web service's IIS application pool - make it so that it never recycles itself or at least does so at an un-Godly hour of the morning or perhaps per 10000 requests.

I know this probably isn't that great an answer, but hope it helps a little!

---

EDIT :

Part of the issue is that the web service isn't 'always' up - it goes to sleep, recycles etc until needed. It would be worth reading up on keeping web-services alive, 5 9s up time etc!

回答4:

I've added these settings on my basicHttpBinding, disabling the automatic proxy detection and gaining a great speedup on first execution time. This of course works well if you are into intranet environment, or you know you do not need any proxy at all.

bypassProxyOnLocal="false"

useDefaultWebProxy="false"

Hope this helps.

回答5:

Apologize for the necro-add, but this issue has come up a number of times for me, and I have a habit of forgetting all the aspects of this issue each time. So here's the list (some of which other people mentioned)

• Change your System.ServiceModel.BasicHttpBinding so that the BypassProxyOnLocal and UseDefaultWebProxy are both false. (You can decide whether you want to do this in a config file or via code.)
• Change the ‘Generate Serialization Assembly’ in the projects ‘Build’ properties to ‘On’ instead of ‘Auto’
• Make sure you’re using a modern .NET framework. 4.6.1 is about 60 MS faster than 4.5.2 on the first request, for instance.
• Do your performance testing on a Release Executable, not within VisualStudio (VS adds a large additional overhead on the initial call that is not reflected in the actual release .exe build.)
• If you're working with a service/site that continually run, definitely consider sending a dummy request to the server upon startup - simply to get .NET to serialize the connection up front. Likewise, if you're writing a run-and-quit app, consider writing a background dummy request while the program is starting up.
• Make sure the service you're connecting to doesn't recycle very often. Every time the app pool recycles on an IIS service, the first request coming in after recycle can take awhile.
• Make sure the service you're connecting to doesn't hibernate. By default, a service hibernates after 20 minutes of inactivity - and the next request that comes in has a delay similar to a post-recycle request.