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.
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)
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)
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.)
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
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.
Related
I setup a web application which was running fine but after doing some testing, I ran it on my server and since the back end job was long, I let it run. Now I tried to load the web application from another machine and it won't even load. Is this related to worker processes and application pools or is there perhaps something else possibly wrong?
I do not want to stop the worker process just yet to check if it then loads.
I stopped the worker process and the web app finally loaded. Does anyone have any ideas to prevent this. It should not be an issue and I am beginning to think that maybe a MVC project would be better.
EDIT:
Thanks Dash; I am looking into it and I do think that it is simply a case of the process locking up stuff and the web application cannot load. Now my question is whether sessions are able to avoid this? I attempted to use background threads and assumed that this would avoid the locking/IO issues but need to rethink this. Any ideas appreciated.
I'm developing a .NET 4 application that requires a backend worker thread to be running. This thread consists mostly of the following code:
while (true) {
//Check stuff in database
//Do stuff
//write to database / filesystem
Thread.sleep(60000)
}
The ASP.NET app is just a frontend for the database.
My question is around where the best place to put this worker loop would be. It seems my immediate two choices would be (1) to spin it off from the Application_Start method, and just let it run, or (2) bundle it in a separate process (Windows service?)
(1) would obviously need some logic in the ASP.NET code to check it's still running, as IIS might kill it. It's also quite neat in that the whole application logic is in one, easily deployable package.
(2) is much more segregated, but feels a lot messier.
What's the best approach?
I would strongly opt for the Windows Service if possible. Background threading in ASP.NET comes with a lot of baggage.
The lifetime of your background process is at the mercy of IIS. If IIS decides its time to recycle the App Pool, your background process will restart. If IIS decides to stop the App Pool due to inactivity, your background process will not run.
If IIS is configured to run as a Web Garden (multiple processes per AppPool), then your background thread could run more than once.
Later on, if you decide to load balance your website (multiple servers running the site), then you may have to change your application to ensure the background threading is only happening on one server).
And plenty more.
Consider something simple like Hangfire and then think about the design points in this related answer.
Throughout the process of developing my Application, the first-response time has got worse and worse, It is now taking 10 minutes to load! I am using Web-Deploy to speed up publishing my changes, and from what i've read on MSDN, i understand that this delay is due to compilation and loading assemblies.
It's an ASP.NET MVC3 Application which uses EF CodeFirst, MVC-MiniProfiler etc. Im wondering if its one of these assemblies that is slowing things down.
Is there a way to track down the long running process plaguing my development/testing process?
As a side note, the issue is nowhere near as bad in the Azure Emulator.
Using Windows Azure SDK 1.4 and later, you have the option to enable Profiling for you application (beside the IntelliTrace). You can read about some of the options available (in 1.5) from my blog post here where you will also find a good screenshot showing the option to enable either IntelliTrace or Profiling.
The trick is that you can only have one of them running (either ItelliTrace or Profiling). So I suggest you first run the ItelliTrace and inspect ItelliTrace logs for any exceptions during your application execution. Then do another deployment using Profiling to catch which are the most time consuming methods.
Please note that enabling IntelliTrace /Profiling is only accomplishable during deployment process, and cannot be changed with simple WebDeploy, so you'll have to make at least two deployments for test.
It's hard to say what the slowdown is - as Awais mentioned, IntelliTrace is your friend. However, the delay might be unavoidable (I have seen this a number of times). If this is the case, you can add a startup script that will "prime" IIS, preventing the problem when the first user hits the site.
What can I do to ensure that when an application/app pool restart is triggered, that the application comes back online as fast as possible?
Better yet, is there a way to prevent the application restart when the usual triggers occur? Like modifying the web.config, global.asax, or machine.config?
There will be an "auto-start" feature in ASP.NET 4.0 (Scott Guthrie talks about it), but that won't help you now.
Please be sure that the Application Pool your website/application is running in, won't go to "sleep" automatically. A default AppPool is set to shut down after 20 minutes inactivty. As i recall this doesn't make the website rebuild, but makes the first request notably slower.
Small note, a website project can also be build, so your App_Code will be empty and your bin folder will contain a bunch of .dll's (just use Build > Build Website). This definitely will makes the first request to your site faster. I don't think a website application will kick in faster than a precompiled website project, but it is just easier to manage.
Yes, moving to web apps will speed up the restart process. Another thing to do would be to make your global.asax as clean as absolutely possible.
Even with web apps, the site will do a restart if any of those config files are modified or if the assemblies in your bin directory change. You can't stop this.
Restart times should be pretty quick at around 2 to 3 seconds. However, I've seen some pretty complicated global.asax files which set up some domain level data that took up to 20 seconds. Of course, they were willing to pay that price because it reduced some of their normal page load times from 3 seconds to .1 second.
Mainly, we use website projects, so I assume that switching to web application projects would speed this up since all of the code files are pre-compiled into a .dll.
When using website projects, I would think that moving App_Code files into an external class library would also speed things up since the code would be pre-compiled.
For Web Application Projects, you can use a Web Deployment Project (VS2010 download link) to precompile the site into a DLL similar to a Website Project does. See the ScottGu article on how to use WDPs.
I've got a similar problem in that I'm running a very high traffic site that gets a good 300+ requests/second. A restart takes a good 90 seconds at least for it.
When I make a change that restarts the server, it appears that the restart stalls until all of the old requests (some of them very long running) close. I can make the restart happen much faster by killing the old w3wp.exe instance manually.
Is there some way to force IIS to close all the connections right away and do a hard restart? Some setting in IIS or asp.net to control this?
I want to add a scheduled task to a client's ASP.NET app. These posts cover the idea well:
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
What is the Best Practice to Kick-off Maintenance Process on ASP.NET
"Out of Band" Processing Techiniques for asp.net applications
My question has two parts: First, will IIS unload the application if there isn't enough request activity despite the Cache activity? My client doesn't enjoy as much traffic as stackoverflow so they can't rely on user requests to keep the app 'active'. Obviously, I can't schedule tasks in an unloaded app.
Second, if so, is there a way to prevent IIS from unloading the app outside of configuration or external 'stay-alive' requests? My client's host doesn't allow much configuration tweaking and a stay-alive utility introduces the deployment complexity I'm trying to avoid with an ASP.NET Cache solution.
Thanks a bunch.
Edit/Conclusion: TheXenocide's solution is exactly correct given the question. However, I've decided it is a really bad question. The temptation to cut corners is always looming. I've regained my senses and told my client to use a website monitoring tool to keep the site active. In addition, the scheduled task is going in a windows service despite the extra deployment hassle.
Unfortunately, outside the range of changing timeout configuration (which I believe to be possible in Web.config, though I don't know what is and isn't allowed on hosting providers, most of which use Medium Trust) I don't believe there is any other method to keep the application from ending beyond web requests. One thing you might try that may be a little more simple than using some keep-alive service on a local machine might be to add some logic to Session_Start/Session_End that ensures there is always at least one session active; you can use the WebRequest class from within your application to call your own site and it should still start a new session.
Good luck, and let us know what you do :)
UPDATE: these details now very much depend on which version of IIS and which version of .NET you're running in. Newer versions of each have methods of configuring "always running" applications.