We have an application which, on startup, populates it's cache from an csv. This takes about 1 minute. We thought putting an application warm up on it would eliviate the problem, but it seems like the requests specified are not being executed. Hitting the application locally will take a minute and then be instant thereafter. I tried several requests, relative (to localhost and application root) and absolute ones, to no avail. It does not work after stop/starting the corresponding app pool, nor recyclying (if there is a difference to application warm up), nor rebuilding the application.
Anyone have suggestions I could try?
Edit: The event viewer does not have anything related to the application warm up (as far as I can tell) and Application_start() is not called
if you're not seeing warmup requests in your logs perhaps you don't have them enabled in your application settings? What language are you using? (Warmup requests are enabled by default for all Java applications.)
I see entries for /_ah/warmup in my logs.
Related
I am working on a .NET WebForms application and I have observed that whenever I build, after the build, the very first page load takes longer to load than usually. This happens even if I wait after building before I load a page. Is there a way to increase human workforce performance by changing IIS/.NET to initialize things on postbuild instead of first page load?
Yes you can, like this.
Quoting:
You can use Application Initialization Module which comes in-box with IIS 8.0, like this:
<applicationInitialization
doAppInitAfterRestart="true" >
<add initializationPage="/" />
</applicationInitialization>
This will send a request to the root of your app (initializationPage="/") every time your app starts automatically.
You can also configure the Start Mode for your application pool to Always Running which means every time IIS restarts, it will make sure to start your application pool immediately (this if from right click on your application pool then Advanced Settings).
Professional servers have hardly any latency, though it requires quite a bit of tweaking. Also, by default, applications recycle regularly on IIS (as well as when some kinds of exceptions occur, when some files are changed, or when some thresholds are reached). Professional web application hosting is anything but simple :) You might get help with that on Server Fault, perhaps.
Another option is to avoid mixing pre-compilation and JIT-compilation - if you only pre-compile, you don't need to do any compilation when the application is deployed, resulting in faster startup times. If you only deploy sources, the application domain doesn't need to be torn down when you make a change, which means that only the change needs to be recompiled, which is much faster.
And of course, ASP.NET Core is much, much faster in both scenarios - it can do the whole compilation in-memory, unlike the legacy system which uses csc to build multiple assemblies, save them to disk, load them from disk, merge them together, save that again, just to load it again and initialize.
I'm just diving into Web API development (ASP.NET 4.6, Visual Studio 2015) and I have a strange problem. When running my web application with the startup option "Don't open a page. Wait for a request from an external application" selected, the initial request that is supposed to kick things off is very delayed.
For example, I start debugging and the VS output window is blank. I figure this is normal. Then in Fiddler I send the initial request. The time it takes for VS to start spitting out debug information and actually spinning up the application varies: sometimes it is instantly, most of the time it is about 10 seconds. Occasionally it will take up to 1 minute. During that time nothing is happening.
Edit:
Clarification: this is a delay before ANYTHING happens (i.e. before bootstrapping/spin-up occurs)
This mysterious delay also occurs when the project is configured to start with the default MVC home page. And it also happens when running without debugging. This happens with fresh project made from the template. Same goes for ASP.NET 5 template app. Also happens when I run in full IIS.
I wonder if it's a problem specific to my computer, as I tried all these things on another machine and there were never any delays.
I found out what was stalling out the HTTP request: my antivirus. I have AVG Internet Security Business Edition on my system. All that was required was to select "Temporarily Disable AVG Protection". Boom--right away, all my HTTP requests came through instantly.
Additional info: I tried disabling individual components from the AVG control panel, but none of those provided the fix. It seems, unfortunately, that it's all-or-nothing with AVG.
Conclusion:
At least on my system, completely disabling AVG (or presumably, uninstalling) AVG is required for ASP.NET development where waiting up to 1 minute for the first request to be processed is unacceptable.
After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).
When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.
Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.
Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.
The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.
Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.
Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –
A bit late to the party, but maybe it'll help someone. For me it was because I accidentally mapped two IIS sites to one directory. This resulted in two IIS background worker tasks and Application Application_Start() being called twice even though the second site was marked as "Stopped" in IIS.
It appears to me that a simple change to a .cshmtl file in my application restarts the application. Honestly I'm not sure it's restarting, but it is painfully slow when I am reloading the page. Does this seem normal? Anyone have any advice to figure out why this might be happening? It makes development a real drag.
I feel like I have time to get up and get a cup of coffee and a cigarette every time I make a change. And I don't even smoke! If this continues, I might have to take up smoking.
If you change your View the Application should not restart. But it takes some time cause your View gets compiled before rendered.
You can set a breakpoint on the Application_Start() method in global.asax to see if your Application gets restarted.
There are so many threads related to Session loss, Cache loss and Application restart. The reason for all of these is that IIS [and yes IISExpress] will restart the app pool when anything in the BIN folder changes. MVC will compile the Razor views of an application on demand. This view compilation will update the BIN folder. The update to the BIN folder will reset the app pool. This clears session and clears cache, and call Application_End.
I have an application that runs perfectly fine locally using the VS 2010 application server, however, when I deploy to our web app machine startup just spins and spins and never loads. We have other apps on this same machine that load just fine (this is a debug deployment of same app in product).
I have been spinning my wheels on this for days and I am at a loss as the problem could be.
Here is what I did
Create a new directory (same level as other apps)
Copied over our existing test (www.domain/test/) and it works fine
Build and publish new debug app (www.domain/test/) and it just spins trying to load first form.
I know the diretory is "working" as the 'test' application I put there works fine.
If it's killing the App pool, you might get something in the event log. Fiddler (www.fiddlertool.com) is great http debug tool which let you see if you're in a redirect loop. Also Firefox shows a more meaningful error, something about exceeding the max redirect count.
It does sound like something is looping, but not quick enough to cause a stack overflow, which is odd, because you'd expect it to fail every time.
Simon
Do you have the ability to remote desktop into the machine? If so try running process explorer and look at the process details for the worker process that is giving you issues. Definitely look at the TCP connections being created. If your processor is pegged at 100%, and memory usage is rising then you probably have an endless loop running.
It sounds like it's more related to IIS than ASP.NET. What about the identity that the website is running under? Is it possible that the user the site's running under a bad user, or maybe the password needs to be re-entered?
I did a quick Bing search
There are a lot of postings regarding the error message you described above. Most if not all point to code in your app that is crashing. I know I had a similar problem when I used an automated/threaded daemon utility in my web application. Make sure your code is not bringing down the server, sometimes the VS2010 web server is a little more foregiving than an actual IIS deployment.
If that doesn't work try running a Remote Debugging Session to try and catch any errors being thrown but not handled.
Lastly you could try to setup a new local IIS server to see if you have the same problems. Scott Gu has a nice article about using IIS Express to do this.