ASMX Web Service slow first request

I have a bunch of .NET Webservices running in one IIS Application. These webservices are consumed by another IIS Application (frontend). The first call is pretty slow, about 5 to 10 seconds. After that it’s just milliseconds. The first call is considered a performance problem.

We’ve tried an application that calls all these webservices but this obviously doesn’t solve anything. So it's not the default Application Recycle that is the problem. I've created an application that just initializes the service several times and measures the time it takes to create one instance. Before running this application I ensure that my webservice application is started / recycled, then I run the application. The first initialization takes between 2 to 4 seconds, all others is just milliseconds.

Another thought is that we create a page in the Frontend application that initiates all the webservices and that we call this page before any user开发者_JS百科s are in. I don’t consider this as an elegant solution, what else could I try?

The delay that is experienced when a client is calling a webservice for the first time is caused by the fact that by default a XmlSerializers dll for the webservice needs to be compiled. This is causing the 2-4 seconds for the initial call. Of course this is the case when the webservice application is already running, if it's not you would have a recycle. In which case the other answers could help.

To speed up the initial call you can create the XmlSerializers dll at compile time. You can do this by setting your project build 'Generate serialization assembly' to on. This generates an MyApplication.XmlSerializers.dll containing the webservice information. Now the initial call dropped to 300 ms, presumably the loading of the dll. All calls there after take 0 ms.

In Visual Studio right click on your project and choose 'Properties'. Go to the 'Build' Tab. There you have an option 'Generate Serialization assembly' in the 'Output' section. If you change the value to 'On' the serialization assembly will be generated during compile time.

The first time you call the webservice, or the first time after a long delay, the web service needs to start up. This is where you're seeing the delay. After that, it's already started and will respond really quickly to calls. This is standard web service behaviour.

You could configure IIS to have keepalive = true - which may improve the performance.

More information as requested.

It could be that the serialization assemblies are being created at runtime. You can change the settings of the serialization assembly using the dropdown at the bottom of the Build pane of the properties window for the project.

It could be that you have written your web service to perform a lot of operations on application start, which would happen the first time a method on the service is called.

It might be that the operation is very slow, but you are then caching the response, which makes subsequent calls faster.

I recently discovered that in our ASMX-files we only referred to the class name. We got the service implementation in a different assembly for each ASMX-file. This causes .NET framework to scan through the entire bin-folder looking for the assembly containing the implementation. As your webservice application grows this will consume more time. This can be solved by not only including the class name in your ASMX definition but also the assembly name.

Our ASMX looked like this:

<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice” %>

If you change it to include the assembly that contains the implementation it would look like this. This saved us around 10% of our initial load of the webservice application.

<%@ WebService Language=”C#” CodeBehind=”MyService.cs” Class=”MyWebservice, MyWebservice.Implementation.Assembly” %>

That is typical, since ASP.NET apps compile and load the bin\ directory into memory at first request.

Things to do first:

Remove all unnecessary dll's in your bin directory. (I've seen people ship nunit.dll)

Precompile your ASP.NET app so that IIS does not need to. See "VS 2008 Web Deployment Project Support Released"

Not sure if this will solve slow spin up of the WS on the "very first time", as I assume there is a load of compiling and .net DLL's being loaded, but you can almost eliminate any future cold starts by ensuring the application pool the WS is in is configured correctly.

By default, IIS6 has "respawn" on idle, after a number of minutes or "recycle" events that effectively restart the WS each time. If your happy the service is stable then these are not needed.

Ensuring that the WS has it's own dedicated application pool (is not sharing an inappropriate pool) is also a strong recommendation.

After several hour of insane testing, i has been able to reduce the webservice first-run execution time to bare minimum from two host in the same IP class (below 300msec)....

I experienced at first an initial delay of 2-3 sec at first webservice call, than any subsequent call from the same process to be very fast.

The key for understanding the delay in my case was how client handles WEB PROXY !!

This is my new binding in app.config file:

  <basicHttpBinding>
    <binding name="CreateContextSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
        receiveTimeout="01:00:00" sendTimeout="01:00:00" allowCookies="false"
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
        maxBufferSize="16777216" maxBufferPoolSize="524288" maxReceivedMessageSize="16777216"
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
        useDefaultWebProxy="false">
      <readerQuotas maxDepth="32" maxStringContentLength="1048576" maxArrayLength="16384"
          maxBytesPerRead="65536" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
            realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>

The first webcall execution i suppose to be much slower because transport channel need to discover proxy configuration on initialization, in order to transparently connect to internet. This is usually not needed into intranet environment, thus i have changed these binding settings to avoid use the default proxy (automatically discovered from explorer settings):

bypassProxyOnLocal="false"

useDefaultWebProxy="false"

The first-call connection time is now reduced by a large amount. Hope this helps.

Sorry for the necro add, but this has been an ongoing struggle for me as well, and I wanted to add some info to the picture. VisualStudio itself adds a rather large component to the time. Here's the basic test, involving a bare-bones forms app and an already-running webservice hosted internally on a company server (with Generate Serialization Assembly set to true for all tests):

Running in VS, Debug:
    First Call: 400 ms to set up client object, 450 to call function
    Second Call: 1 ms to set up client object, 14 to call function
Running as .exe, Release:
    First Call: 20 ms to set up client object, 70 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running the Debug's .exe file outside of vs:
    First Call: 20 ms to set up client object, 80 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running as Release within VS:
    Similar results to Debug in VS -- very slow

Short story? Visual Studio is adding a large chunk of time to the picture. Instead of ~90 ms, it's taking nearly a second. So if you're doing performance tuning, make sure you do your testing outside the VisualStudio environment.