First webservice response is slow even with Application Initialization module installed

Question

A test WCF webservice that I have hosted using IIS 7.5 is consistently slow to respond to calls made after a period of inactivity (i.e. the first call of each day).

From researching this topic I gather that the problem of "application warmup" is commonly encountered when using IIS (e.g. see here).

I have taken the usual steps that are recommended to try and mitigate this problem:

• Installed the Application Initialization Module.
• Disabled the application pool Idle Time-out, and the Regular Recycling Time Interval (i.e. set them to '0').
• Edited the applicationhost.config file so that autoStart=True and startMode="alwaysRunning" for the necessary app pool, and preloadEnabled="true" for my application.

With these settings, I expect the application pool to immediately spin up a worker process when IIS is started, and spin up a new worker process when the existing one exits. Also, I expect the application to be loaded within the worker process.

However, for the first call of each day, the logs show the difference in time between the client making a call, and the webservice receiving the call, can be as much as 10 seconds. Subsequent calls are typically handled in well under 2 seconds.

Curiously, the long response time is not reproduced by making a call following an iisreset command. I would expect that such a heavy-handed operation would put the webservice in a similarly "cold" situation, however this does not seem to be the case.

I would like to know:

• What could still be causing the delay in the application "warming up"?
• What is the difference in the state of the webservice following iisreset and a long period of inactivity?
• Should I resort to a "heart beat" solution to regularly ping the service to keep it alive?

Thanks in advance for any tips or insight.

Answer 1

I'll try to help with you questions:

What could still be causing the delay in the application "warming up"?

Warm up an application does not mean warm up its resources. For instance, if you configure Auto-start with Application Fabric in your WCF application (https://msdn.microsoft.com/en-us/library/ee677260(v=azure.10).aspx), and this application access database using EF, it will not initiate your DBContext. If you want these resources initialized after your application warmed up, you need to implement a method to initialize your resources, like cache, DBContext, etc.

What is the difference in the state of the webservice following iisreset and a long period of inactivity?

When the application spend long time of inactivity, probably the application pool goes down and it is restarted when it receives any request, like a recycle does. This link has interest information about the difference between iisreset and application pool recycle, and it can help to answer your question: https://fullsocrates.wordpress.com/2012/07/25/iisreset-vs-recycling-application-pools/

Should I resort to a "heart beat" solution to regularly ping the service to keep it alive?

If you keep on accessing your service, it will probably keep its resources initialized in memory, so can be a good approach. Anyway, if your Application Pool is configured to recycle in some interval time, it will be recycled and your resources in memory lost. If it looks problem to you, just turn off this feature going to IIS -> Application Pool -> Advanced settings and set Regular Time Interval=0 For this issue, it's just some suggestions, you need to make some tests and find out the better solution.