10

I have an ASP .NET web application which on the backend is talking to an ASMX web service. We have counted and the average wait time for the initial request is 20s. I am wondering if there is a way I can send the web service up to the server precompiled, thus negating the need for compilation.

We have also noticed that IIS tends to recycle its worker threads and this also causes a compilation. The process itself is not accessed terribly often, but it needs to be much quicker when it is.

Any thoughts?

Thanks in advance

Update: thanks to all the suggestions, I have tried a number of them and here is what I have found. Recycle time shutdown/tinkering is dangerous cause I dont want threads to just sit around doing nothing. Upon further inspection the site is going up precompiled, so my question is why is there an initial spin up time for a web service?

Right now: Leaning towards the warmup script suggestion below

Update: The service is being hit from a web server on a different machine. We are seeing problems with the initial request only.

xximjasonxx
  • 1,192
  • 2
  • 11
  • 27
  • If we could get it to the point where NO compilation was necessary, ever besides before I move things to the Virtual Directory, I think that would be optimal. Is that even possible? – xximjasonxx Mar 01 '10 at 21:47
  • If you precompile then your problem is not IIS compilation. Startup time for web app is one thing and compilation is another. – Vnuk Mar 02 '10 at 15:21

5 Answers5

7

One alternative approach is to write a "warm-up script" which simply executes one page from your app. This will make the server spin-up for you and the next person will get a fast hit. You could also set a scheduled process to run that script occasionally (like, if you schedule the thread pool to recycle at 4 am, schedule the warm-up script to run at 4:01 am)

tgolisch
  • 6,549
  • 3
  • 24
  • 42
  • 3
    I configured the free [tagBeep uptime monitoring](http://tagbeep.com) for several of my websites. This has the side-effect of generating the warm-up automatically, since it periodically checks my websites every 5 minutes for being available. – Uwe Keim Jun 26 '12 at 15:02
3

You should be looking to perform precompliation as part of your build/deploy scripts.

Having a post-deployment activity to programatically request each web resource and trigger compliation seems pretty daft to me.

Thomas' answer gives the compiler, there's also a guide over at the MSDN, How to: Precompile ASP.NET Web Sites.

If you're using MSBuild then go for the AspNetCompiler Task.

(I probably would have made this a comment but I'm not yet allowed... not enough SO juice)

Dwight Gunning
  • 2,485
  • 25
  • 39
  • This seems to be along the lines of what I was looking for. Going to give it a try, thanks – xximjasonxx Mar 02 '10 at 13:46
  • 1
    Will this affect the web services also? I already use this in my deployments using Web Deployment projects but regardless of it being precompiled there is still a definite initial load up time for the first request that I still always make sure to make the first request after deployment, it's just shorter than not doing this. – Chris Marisic Mar 02 '10 at 13:59
  • So apparently my site is already precompiled, what gives then? Why is this thing taking 35s to come back on the initial hit? – xximjasonxx Mar 02 '10 at 14:07
  • From the question I wasn't sure if the delay is caused by the website itself or in the secondary web service request. If you haven't done so already, pinpointing the source would be next step. – Dwight Gunning Mar 02 '10 at 15:10
2

Have you tried using aspnet_compiler in the framework folder (e.g. %SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727)?

You can control ASP.NET recycling via the settings on the Application Pool. If it is recycling more often than the settings then something else is causing that (e.g. changes to the web.config etc.)

Thomas
  • 63,911
  • 12
  • 95
  • 141
  • What can I look for in the web.config that might be contributing to the problem? – xximjasonxx Mar 01 '10 at 21:44
  • Any change to the web.config file will cause ASP.NET to recycle the app pool. So, if there is code that is altering the web.config file that would definitely do it. The first place to look however is the application pool recycling settings. If those are all off and the app is recycling, then something else is forcing a reset of the application pool (or IIS itself). – Thomas Mar 01 '10 at 22:15
  • Right, but what I am worried about is if I set the thread recycle too high, I might run out of threads. Thoughts on that point? – xximjasonxx Mar 02 '10 at 04:01
  • ASP.NET uses the thread pool by default. That pool has 25 per processor if memory serves. That means for you to exhaust the pool, you have to be spawning more than 25 threads simultaneously on a single processor machine. Once a thread is discard, it returns the pool to be reused by .NET until some threshold is hit in which case it will kill the thread. When you recycle the pool, you dump the worker process and all threads that were running. If the worker process hits the max on the thread pool, other requests wait until a thread is available. – Thomas Mar 02 '10 at 05:52
  • You know, it occurs to me that thread pool exhaustion might be the issue here. Each web service call is going to use a thread from the pool. If you have lots of request to lots of services or services that are slow, you might be exhausting the pool. Have you tried increasing the number of worker threads on the app pool to 50 or so and see if that helps? Here is a MS article that provides more info: http://support.microsoft.com/?id=821268. – Thomas Mar 02 '10 at 06:07
  • Here's the thing, I want to simply keep IIS running as normal and just not have it compile on the initial hit. If that means hitting it before the call is made to force compilation so be it. But i think tinkering with Recycle and Idle shutdown here is not the answer – xximjasonxx Mar 02 '10 at 13:50
  • So apparently, as one would expect, the site is precompiled when publish is performed. What gives then? Why is there this insane spin up time? – xximjasonxx Mar 02 '10 at 14:08
  • When you say it is precompiled, have you enabled "Generate serialization assembly" in VS? This will compile the XmlSerializers into its own DLL at runtime. – Thomas Mar 02 '10 at 16:53
1

Try to disable application recyling in the configuration of the page or application pool in the IIS.

IIS 6 (If i remember correctly): Rightclick on AppPool -> Tab "Performance" -> Uncheck "Shut down working process on idle time"

IIS 7.5 There is property (seems to be an appPool settings too) that shuts down the AppPool after X minutes of idling time. The value 0 is equal to "never shut down"

Hope this helps

citronas
  • 19,035
  • 27
  • 96
  • 164
  • Thanks for this, I was around this area, but I just made Recycle timeout super long. It didnt seem like a good idea, cause I figure I do want the threads to recycle so IIS doesnt run out of threads. Try this, lets see if it works – xximjasonxx Mar 01 '10 at 21:43
  • Did our test this morning and startup hit its longest yet, 35s to respond. So no good, thanks for the suggestion though – xximjasonxx Mar 02 '10 at 13:44
  • First startup after deployment, or first startup after a period of non using? – citronas Mar 02 '10 at 17:15
  • Both, but what we are thinking is that with normal usage and some extension of the recycle period, we should be able to cover the case 98% of the time – xximjasonxx Mar 02 '10 at 18:10
1

At a previous position we had similar issues with WCF services when initially spooling up we bypassed this by creating a simple program that would invoke all our web services after a deployment.

You could also use this same type of program as a keep alive service and just ping the services every 5-10 minutes etc.

Chris Marisic
  • 32,487
  • 24
  • 164
  • 258
  • This is something that was suggested, but its a bandaid IMO. Which is not to say I wont end up using it, I just want to try other things first – xximjasonxx Mar 01 '10 at 21:43