I have one doubt here , I have one asp.net MVC web application and every night we are recylcing the applciation pool from IIS. Now when the next day first request comes it is taking time to get response.
First request it is taking time because app domain is not loaded (application is not started) to start web application it takes some time.
Now the question is does the just in time compiler will come here again ?
Means every morning it needs to recompiled by JIT again ?
Yes, the application will be compiled from IL to executable code again after the recycle: Throwing away the appdomain will also loose the JITed native images.
You could, for instance, avoid some of the compilation by putting dependent assemblies that don't change often in the GAC, and use NGEN on them. That could possible speed up things a bit.
JITting will normally not have a huge performance hit. Cold startup of the IIS process, starting your AppDomain and loading your assemblies from disk will probably have much higher impact. Also, your application might have some custom startup logic in the global.asax file (reading stuff from db). And don't forget your database might have to wake up as well.
Related
I'm working in an ASP.NET MVC 4 application, and on app start up I'm looking using BuildManager to get all referenced assemblies.I'm looking through all types in the application to find a few that I want (it's dynamic so I don't know what types I need until start up).
Essentially my code looks like this:
var allTypes = BuildManager.GetReferencedAssemblies()
.Cast<Assembly>()
.SelectMany(a => a.GetTypes());
I'm calling this on app startup but also at the beginning of each new request in order to dynamically find types.
So my questions are:
Since ASP.NET doesn't load assemblies until they're needed, by calling BuildManager.GetReferencedAssemblies() am I loading ALL assemblies before they're needed and causing a performance issue?
Is iterating through all types a bad idea for each request? I could cache the types but ASP.NET has the option of loading assemblies dynamically after I've cached them, right? If so I may miss some types which are indeed there.
Thanks!
Don't do it every request: do cache as early as possible; reflection is slow.
Pre-load all the assemblies and do it on app-startup; I have a system that I use in a lot of our websites which has to do a lot of dynamic stuff based on deployed assemblies, and I do all the work on startup.
Yes startup is therefore slower - but that's less of a problem than each request taking longer.
You will then most likely be interested in a question I asked and answered a while ago about how to preload all deployed assemblies reliably: How to pre-load all deployed assemblies for an AppDomain.
I still use the same process to this day and it works like a charm.
If I make a change to a razor view, recompile, or wait 15-20 minutes, a page might take anywhere from 3-20 seconds to render on that first hit. I understand that the view needs to be recompiled after a change. I also understand that the application will be unloaded after a period of inactivity, but I thought that would be a one time penalty on the very first hit. But for me it seems to apply to every single page.
Take, as an example, my homepage. According to YSlow it's a "B" with 15 components and weighing 250K (that's including MiniProfiler's extra jquery reference). From MiniProfiler I see about 500ms on the first line (http://localhost:80). I'm assuming this includes the view compilation. But then I see 1200ms for Find:Index. There are no SQL calls. Total load time on the first hit is about 3000ms, subsequent hits are about 40ms.
On another page with a couple of partial views, the parent view takes 2400ms to "Find", one of the partial views takes 1000ms to find. The parent view also takes 3200ms to "Render". And the biggest impact is on the first line (http://localhost:80/User/Dashboard) which was a whopping 7000ms. This page has only 3 queries with a total query time of 100ms. The total time to load was more than 15000ms. Subsequent hits are about 250ms.
Our setup is ASP.Net MVC 3, Ninject, EF4.2, Razor view engine, ELMAH, NLog, Html5Boilerplate, and MvcMiniProfiler. I created a duplicate project and removed Ninject, ELMAH, NLog, and MvcMiniProfiler. Performance was only marginally faster. We have about 15 controllers and about 40 views, all in one area.
Is this normal performance? When we deploy to Azure, it's even worse (naturally) than testing locally. Are there suggestions for improvement?
Edit:
A first hit after compile on IIS/localhost (in release mode and with compilation debug=false) can be about 15 seconds. The Azure deployment, running in release, has a faster first hit, but still in the range of 5-10 seconds. I tried David Ebbo's project but didn't see anything dramatic.
Do you deploy this application frequently? If so, then I can see why the first hit performance can be of concern.
We deploy often, and have created a separate project to "warm up" our deployments. It is a unit test project that uses WebDriver to hit each uncompiled view in our app after it is deployed.
Basically, you just use the WebDriver API to fire up a browser, then Navigate() to each URL that needs compiled. Run it once, and the deployment is warm.
Also, in Azure, you can turn off the idle timeout, so that your app never gets idled. We use this script:
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00
... and run it during the Azure deployment like so:
<Task commandLine="startup\disableTimeout.cmd" executionContext="elevated" taskType="simple" />
I am using ASP.Net4 MVC2 for my application. The first person using the application usually experiences a long wait before the application responds. After that the application is pretty responsive. If the application is idle for 15 minutes, the same person or the next person using the application will experience long wait again. It looks like the application compiles after being idle for 15 minutes. Can someone tell me where I should look to trouble shoot the problem? Thanks.
It is almost certainly the case that what you are experiencing is app pool recycling. It's true it takes some time to re-initialize after the pool has been recycled, but it shouldn't take all that long. How long is a "long wait"? A second? Several? In IIS you can configure how regularly your app pool recycles. For IIS 7, right-click on your app pool and choose "Advanced Settings" then look at "Idle Time-out". You may consider increasing this value. (Or set to 0 to disable completely.)
You need to accurately diagnose the problem first before you start implementation solutions. First have to verify if it is, in fact, an app pool recycle. You can start by adding this section to your web.config:
<healthMonitoring>
<rules>
<add name="Application Lifetime Events Default"
eventName="Application Lifetime Events"
provider="EventLogProvider"
profile="Default"
minInstances="1"
maxLimit="Infinite"
minInterval="00:01:00"
custom="" />
</rules>
</healthMonitoring>
It will log an event to the windows event log anytime asp.net recycles itself. It will also gives a reason for the recycle (e.g., someone poked web.config, etc.). If it is a recycle, then you need to figure out why it is recycling. Is it because IIS is set to do it no matter what? Is it because your app is not handling memory correctly and memory pressure is causing asp.net to want to recycle itself? These questions must be answered first.
First determine if it is a recycle by adding to above configuration and why. Once you get the answer you can check memory, etc.
Have a look at the IIS7 application warmup extension.
http://www.iis.net/download/ApplicationWarmUp
I used System.Timers.timer in global.as in asp.net to set a timer for scheduling execute a
function
let' say transferMoney().
But it seems that this timer might stop after several hours unexpected.
And this cause that all the actions are pending.
I want to know whether there are any better methods to set up a timer in asp.net, MVC 1.0?
Thanks in advance!
It might just be because the application got recycled. Global.ashx is not really the right place to do long running tasks because if your AppDomain gets recycled your timer will die. I suggest making a job windows service instead.
Edit: Well, it's fairly easy to create a windows service project in Visual Studio just do [File] > [Add] > [New Project...] > [Windows] > [Windows Service] and you will get the stub code for the project.
It's hard to come up with a complete example so i suggest you google it. ;) There are tons of samples out there for you to look at.
This article on CodeProject seems to be a good introduction to Windows Services.
Any timer you'll use in ASP.NET apps will eventually "terminate", but this a very expected behavior due to process recycling.
The timer will never work because IIS will reschedule the worker process regularly based on Application Pool settings, so when it recycles your timer will get destroyed and you might need to reopen it.
You can put a check on whether timer object is still available or not, if not available then create it !!, using any other timer object will not work. But this still has a problem, because if you dont have any web request for particular period of time, it will still get destroyed. Best is to setup a ping monitor from other place which can keep your website alive.
You can't reliably run a timer in ASP.NET. If there are no requests coming in, the IIS can shut down the application, and it will not start until the next request arrives.
Why do you think that you need a timer? In most web applications this is not needed at all to do periodical updates unless they depend on an external source.
If you are just moving data around inside your application, the actual transactions doesn't have to happen at an exact interval, you only have to calculate what the result would be if they had happened. Whenever a request comes in, you calculate how many transactions would have happened since the last request, and do them to catch up to the current state.
If your transactions rely on an external source so that they actually has to run at a specific time, you simply can't do it with ASP.NET alone. You need an application that runs outside IIS, for example started periodically by the windows scheduler.
You could try the system.threading.timer
http://msdn.microsoft.com/en-us/library/system.threading.timer.aspx
When we created our program, it closed properly under XP, but under Vista, even though the program is closed, the process is often still running until I open task manager and manually kill the process.
Any suggestions on how to make sure this is closed when we close the program? What a pain.
Mark Gundy
www.magchat.com
The debugger will be your friend here. Step through the shutdown until you get stuck. That'll be the best bet.
But... assuming for some reason the debugger is affecting the behaviour, or can't be used for some other reason:
A few earlier replies suggest using FastMM. This has been the default memory manager for delphi since D2006. You can try flipping on the options to report memory leaks... but that'll only work after you've finished shutting down the process, which is what isn't working. :) So I doubt it will help you much in this case. The full version of FastMM, as opposed to the standard one packaged with delphi, might have some other helpful features... But I can't recall any that would help here.
To inspect your app while it's stuck, you could try the sysinternals tools, like Process Explorer & Process Monitor. Process Monitor may show you if it's choking on any ACCESS_DENIED errors, etc, and the stack trace at the time of the error. Process Explorer could be especially useful, by listing all the handles your process is still holding open, and allowing you to view the stack of all its living threads. A familiar function or two, in the stack traces of any hung threads, may send you hunting in the right area.
Are you using multiple threads? If one of them can't terminate for some reason, it'll hang the cleanup process.
The short answer is that you have a bug in your application. So, have you tried debugging it?
If you have the Delphi IDE installed on Vista, run the app from the IDE and break it when it 'hangs'. Chances are that you'll have a thread that hasn't terminated itself, and the VCL is waiting for it to finish.
If you don't have the IDE installed on vista, you can probably use the remote debugger, but I'm not familiar with this.
What do you call to close your program? Try using
Application.Terminate;
To force all forms to close and the process to exit.
It probably means you have some memory leak - some resource is not released.
If your application instantiates COM objects, check that you properly close them.
If you use older version of Delphi, you can try to locate possible memory leaks with FastMM
Edit, examples as requested:
I had two situations where application sometimes would stay resident in memory after exit. Both applications would disappear from taskbar, but they would be still active - visible in task manager. Both applications were created with Delphi 7.
First application has one main window with panel in which ather forms are embedded. Each form is standard TForm. Each form is created first time user requests it. Everything worked without problems in test environment, but users reported that from time to time, application would remain in memory, usually after longer usage - when user displayed almost all of the forms in application. I could not replicate this behavior while testing. That was first time I found out about FastMM. When I first run application with FastMM, it reported that some of forms embedded in main form were not released. This version was tested at user site and it turned out that 2 forms that have lots of data aware components would hang up and prevent application from exiting. When I added code that makes sure that all created forms are released before main form, application never hung up on exit.
Second example is application that uses COM to activate GIS editor (Geomedia) to manipulate some map data. I imported type libraries and created Delphi wrapper object. Some of created objects were not freed when application ends. Application icon disappeared from task bar, but application and GIS editor were still active and visible in task manager. Again, it did not happen every time application run. I included FastMM in application and it reported that some objects were not freed. I made sure that every created object gets freed and after that application did not hang on exit any more.
... and if you need to close single form, then use:
Form.Close;
GUI AND HANDLER DELETED. Reference and some parts of memory is left to provide access to variables, constants, etc.
If you need to hide ( something like Minimize, only GUI is cleared ) form, then:
Form.Hide;
GUI is cleared, leaving internal resources untoauched ( reference, handler, memory )
If form is dynamic ( created at runetime ), then use:
Form.Destroy;
ALL RESOURCES WILL BE CLEARED FROM MEMORY, leaving reference and handlers attached so you could access its location in memory.
If form is dynamic and you will not use it for the same interface, then:
Form.Free;
ALL RESOURCES, REFERENCES, HANDLERS ARE DELETED. I recommend to use this to VCL TComponent class, not for TForm class.
Also, there is Form.FreeAndNill, but my guess that it deleted all memory and loaded handlers, only allowing to use same memory space in the same interface again... (I might be wrong though).
P.S. I hope I am not writing wrong things as the last time I read the theory was a long, long time ago... and it was about Destructor DESTROY in general ...
P.P.S ALSO PLEASE BE CAREFUL if you're writing a Vista-ready app - that it includes UAC Handling with manifests / runtime code and SuperBar compatibility requirement. Also Aero requires some additional megabytes to output file due its Aero feature ... :P