views:

3186

answers:

6

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 users are in. I don’t consider this as an elegant solution, what else could I try?

+3  A: 

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.

Sohnee
That's a very nice suggestion. Unfortunately the system administrators have a daily reboot policy.
Smazy
@Smazy: do you know their reasoning for the policy? It sounds like they've still got the Win95/98 fear. Do they require all computers to be formatted and have their OS's reinstalled every 3 months too? :-D
STW
Hi Praesagus, more information added as requested.
Sohnee
Thanks for additional information :)
Praesagus
Not a problem! Hope it helps.
Sohnee
+1  A: 

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"

Chad Grant
his person profile have a bad link
Frankly, so what?
Marc Gravell
+1  A: 

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.

Guy
+4  A: 

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.

Smazy
Interesting. The default setting of "Auto" should do this at compile time according to the docs. I wonder if you are precompiling any of the sites? Precompiling both client/server should solve all your startup issues I would guess. Now that I understand that you are calling a webservice from another web app ... I just wanted to warn you about that. The performance is terrible and doesn't scale at all. The serialization from objects->soap over http and back from soap->objects is rough.
Chad Grant
So if I understand this correctly, you better always generate a XmlSerializers dll for webservices which improve the initial load performance without any down-side, besides that there are now 2 dll's?
freggel
This is perfect, thank you. For reporting services specifically, this will make a huge dfference. http://stackoverflow.com/questions/751762/slow-startup-of-sql-reporting-services-2008-in-native-mode
Praesagus
+1  A: 

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” %>

Smazy
Thanks for the update on this!
John Saunders
A: 

I think it's not the default Application Recycle that is the problem.

Eugene Radulov