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?
Related
I have several projects in asp.net and in all of them I have the same problem. The first time I access an aspx page the load is very slow. Once I close the page and reopen it, the load is very fast. Why is the first load so slow? Can I change any settings in IIS?
Thanks
I have read a lot of documentation but I am not an expert in this and I have not gotten any progress.
By default, asp.net web pages and code files are compiled dynamically when users first request aspx page from a Web site. After pages and code files have been compiled the first time, the compiled resources are cached, so that subsequent requests to the same page are extremely efficient.
More information about asp.net dynamic compilation:
Understanding ASP.NET Dynamic Compilation.
How to: Precompile ASP.NET Web Sites for Deployment.
Ok, so several issues here.
You don't mention if you are talking about your developer computer - say hitting f5 to run the site.
next up, are you deploying a asp.net web site, or a asp.net web site application?
With a application then the compile of the code and pages occurs on YOUR computer, and the .dll's are built by Visual studio (VS). So, at deploy time, then there is a first-time delay, but it not all that long - maybe 5 seconds, and that's as app pool etc. spools up.
However, if you deploy a asp.net web site? Then unlike an "application", the source code (vb, or c#) pages for code behind are included, and deployed to the web site. And this means that IIS does the compile of pages - and often on the fly. This deployment model is often preferred by many, since you can open even the live files on the server, edit one line of code behind, hit save. On next page use, it will re-compile.
If you use an application, then as noted, IIS does not do the code compile, and in fact not even the source code is deployed during a publish. Of course, while there are many benefits to an "application", the ONE big downside is of course that you require a full site re-publish EVEN if you change just one line of code behind.
So, while an application has "some" delay for the first site use, it tends to be considerably less of a delay compared to when using/deploying a web site. (Since then, IIS has to compile the code, and in fact has to compile each page used).
You don't mention/note which deploy model and approach you are using here.
As noted, while the web site option is certainly less efforts to make a change to one page or a bit of code, I still far prefer the "application" approach, since things like "referencing" additional class library and code, and even being able to say use the Rosyln compiler (which may well not be on the server and available to IIS). As a result, I prefer and use an "application" despite the extra efforts required come publish time, but the benefits at developer time far outweigh the downsides.
And of course, one benefit of the "application" approach, is you do as a general rule get far faster web start up times.
I have a problem with an old application in asp.net.
This application runs on a server with windows server 2012 and is used by hundreds of people at the same time (same app but which is pointed to by different domains).
The problem is this: every time I modify an .asp file, the page takes a lot of time to "recompile" the code and this causes damage to the users who use it.
This problem does not occur with the exact same application but running on another dedicated server used only by one user.
I've been researching for days, the only noteworthy thing found is that, in the server iis, if I recycle on application pool -> select the application, it has exactly the same effect.
I don't know much about windows server so I ask you for help.
Thank you!
You have two types of deployment models.
First is what we call a asp.net web site,
and then second, is what we call a asp.net web site application.
They sound the same - but they are not.
So, while most perfer using a "application"? The ONE down side is that you have to re-publish the WHOLE site if you say change some code behind. This is good, and bad. The good part is that your code is re-compiled BEFORE you publish. (and in fact, you might even want to re-name "app_code", since that does re-compile by the web site.
However, for the most part a web applcation is "harder" to make a small update, since when you publish, you have to re-publish the whole site. But, the good part is that all code tends to be compiled down to ONE .dll. In effect the the site is pre-compiled before publishing. And with a applciaton, then you can add/change and do more things. In effect, the web site "applcation" allows you to do things like create say a custom logon provider. In most cases, this means the WHOLE site is under your developer control. It also means that code behind (source code) is NOT pushed up to the site.
Then you have what is called a asp.net web site. This allows you to say modify the code (code behind) of one page and then push that one page (and code) up to the site. The web site will thus re-compile that one page. You will note the "delay" that you experiance - but it ONLY occures the first time that page is published.
So, for a "application", you will in Visual Studio open up the project (and a sln file) is used.
For a web site, you from Visual Studio go open->web site.
I hands down prefer web applications, but they are MUCH harder to deploy a small change, since as noted, you have to re-publish the whole site.
However, the two different choices would thus explain the "difference" and as to why the other site don't experience the delay as much as you are. However, usually on first load - there can be a one time delay after a re-publish. And this quite much means the site is down for this time to re-publish.
Also, do keep in mind that if you do modify some files (such as web config), then this WILL cause the app-pool to re-start. (and if you not using sql server sessions, but in-memory sessions - they get blown out when you do this).
It also somewhat possible that the server with one user has more memory, more CPU and a much lighter load - so the reduced delay after making changes might well be the light load on that server.
However, the above two different publishing models and types of asp.net sites would be the first thing or at least the first issue to be aware of.
First, you need to determine if it is a website or web application project (https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1). Default for web application is rebuild for single page changes while default for website does not force recompilation except if special folders or files are modified. You may check to see if any settings for the app pool differ-- in particular "Disable Overlapping Recycle". You may also check the web.config as there may be a setting that is forcing rebuild. You want also want to look at Explicit Complication/pre-compilation option.
You may want to reference the following resources: https://learn.microsoft.com/en-us/previous-versions/ms178473(v=vs.140)?redirectedfrom=MSDN
https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/determining-what-files-need-to-be-deployed-cs
https://learn.microsoft.com/en-us/previous-versions/aspnet/dd547590(v=vs.110)?redirectedfrom=MSDN#Anchor_1
Optimization setting
https://learn.microsoft.com/en-us/archive/blogs/davidebb/a-new-flag-to-optimize-asp-net-compilation-behavior
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.
I have been programming in php for a while, and recently I started a new job ago where I am now programming in c#/asp.net.
While asp has decent performance when deployed, there is one thing that has been bugging me for the past few months. After any code change it takes about 30 seconds for the page to reload for testing.
I guess it is doing the JIT compiling or something. But it can be REALLY frustrating, especially if I am concentrating, and want to test out several incremental changes as quickly as possible, only to have to stare at a blank page for 30 seconds.
Does anyone have any tips to speed this process up?
In Visual studio 2005 every reference you add adds a .refresh file that makes sure the reference did not change since last time and if so brings the new version - if your references stay the same, you can just remove it!
also see here for more tips for VS 2005
Two things I have found:
Try alternating between the "User Visual Studio Development Server" and "Local IIS Server" in your project properties / Web tab. Depending on your project, one may be faster to start and attach to than the other.
If you have projects in your solution, such as CLR-based SQL procedures, they take a few seconds to deploy to the SQL server. If you can afford to remember to turn them back on, or make a separate project config, disable them in the build so they do not get deployed every time you press F5.
Doing those cut my "F5 to live" time from about 20 seconds to 4.
I guess that can be frustrating coming from PHP.
Thirty seconds sounds far too long though. Ensure the basics like free ram etc..
A couple of tips.
1. You do not have to run the debugger in order to run the site. Once you have the site up with the built in VS web server or IIS, you can make your code changes, build and just refresh the page in your browser. No need to hit play and have VS start the whole debug process. If you actually want to debug though, you don't have a choice.
2. Changes to an aspx page do not require a rebuild. I make changes and simply refresh the page to see the result instantly.
Check out the web tab in the project settings to configure how you want VS to handle serving the site. There are some options in there to hopefully help you suite it to your style. ex. I don't let VS launch a browser for me whenever I want to debug. I set the option for it to just wait for a request. Then I can just use the browser of my choice to get started.
Good luck
I feel your pain.
Personnaly I like the ASP.NET website project better for speed of developing.
I don't know if you have that possibility though..
In visual studio do file->new website.
For this project type you don't need a rebuild all the time and you can just refresh a page in your browser when you have changed it. (no rebuild/debug necessary)
I've had similar experiences, it can be slow to recompile at times, but varies based on where and what code is being changed - ie if it is app_code or just page specific.
What sort of hardware are you running on? VS can be a memory hog, and anything less than 2GB seems to make it slow.
Our website has a very long load time due to actions which only occur during the Application Start phase (when the ASP worker process starts). In particular loading commonly used objects from a database into memory was causing a significant delay. We found that using compilation symbols to disable some features when debugging eg security and user roles, helped a lot.
We're developing web applications using DotNetNuke as a framework and our custom modules for required functionality. The problem is, that it takes a long time for the website to load when you do any changes to code. I'm looking at up to 1 minute for each restart, which really is painfully slow. This leads to very slow develop-rebuild-test cycle.
We're using both console projects and winforms projects as testing ground for new functionality for faster development, but still there is lots of UI functionality that has to be done with a browser.
Does anyone have any tips on how to speed up/prevent the appdomain restart that occurs when something changes in the bin folder of a web app?
DNN does a compile on demand when you add/change pages, if you pre-compile them your turn around time should be much faster.
You're bumping up against a drawback of ASP.NET, when used with large web apps.
DotNetNuke has many significant DLLs and VB files that will all have to be reprocessed if all you do is change one single DLL. If you have 50 Module DLL's in your bin, all 50 Module DLL's will be reprocessed by ASP.Net upon your next application request.
Here is my suggestion:
Hook up the following folders to your source control (not your entire DNN folder):
bin (I suggest ignoring all DNN DLL's, so upgrades go smoother)
Portals_default\Skins
Portals_default\Containers
js
DesktopModules (ignore Admin or any built in modules)
images (ignore the core DNN images if you wish, or any of your own clunky images folders like thousands of customer photos)
(optional) CompanyName\ (where you might wish to keep other .NET Projects that need relative access to DLL's in the bin folder)
When one of your developers requires repetitive compiles / page loads, he will benefit most by eliminating as many DLL's in the bin folder as possible. It will also help to use a barebones skin for testing, if you can (They are very easy to make).
The barebones skin (which should utilize 1 or 2 skin objects, at most) and an absolute minimum of DLL's (DNN Core + the bare minimum of your own) will get you the best speed for development.
When your developer is done with the focused development of the one module, he can update those folders which he deleted items from source control (svn here), finish testing his code in the context of the full DLL/Skin set, and he'll be set.
Sometimes it is worth the trouble. I can't get you down to a few seconds of ASP.NET reprocessing, but I can get you down to 10-15 seconds. (assuming you're running on an SSD)
As far as production restarts, make sure your APP Pool recycles during off-hours.
I've looked into whether multi-core setups can somehow decrease this reprocessing time, but haven't had any luck (I have an open question on serverfault)
Maybe this would help you?
Speeding up build times in ASP.NET