I have a Silverlight application hosted in an ASP.NET page. I need to do some processing when the application first starts up and start up some background processes (various periodic checks).
I thought that the Global.asax Application_Start event would be a good place to do this, but I find that the Application_Start fires multiple times which I didn't expect. From what I've read it seems that when the last user logs out of my application their session disappears and IIS unloads my application. When it's next requested it gets loaded again and the Application_Start runs again, which is not really what I want.
Is this the expected behaviour? Is there any way to keep the application loaded and not have it restart like this?
Secondly, I have these periodic background processes that I want to run. Maybe a Windows Service would be a better place for them, but having a timer run from within a static class in my application is convenient. Is there a way I can keep these running even though there are no active users?
I think you are trying to achieve a behaviour which just doesn't fit the web server model well. Many CMSs try to perform periodic tasks etc. by having some user web requests initiate the work, but I have never seen it done with much success.
If you aren't restricted by deployment issues, access rights etc., I would recommend going with the Windows Service approach. Just make sure to incorporate it in your build/deployment process so that that won't become a hazzle.
Related
I have started to use New Relic to monitor the performance of http://alternativeto.net that is a fairly large website.
What I've noticed is that a significant time is spent in a method they report as "TransferRequestHandler" and when i dive into it i see that it's really the "BeginRequest()" method that is taking time.
It looks like this in New Relic.
The closest thing I've come to find anything that could be the problem is this thread here on Stack Overflow I just discovered why all ASP.Net websites are slow, and I am trying to work out what to do about it but i've actually tried to replace the Session Module but that didn't help.
The site is a hybrid between ASP.NET MVC and Webforms.
I've realized that this is a long shot and you don't have much to "go on" but if someone can put me in the right direction and most importantly be able to reproduce the behavior locally or something like that i would be extremely grateful :)
The BeginRequest is the place that everything starts, so its normally there to be the delay but you must go deeper to find the actually point of your code that makes the delay.
If the session is the issue, then disable the session when the user make long actions, like download a file, or complicate procedures that the page stuck for long time.
relative to session:
call aspx page to return an image randomly slow
ASP.NET Server does not process pages asynchronously
Trying to make Web Method Asynchronous
Web app blocked while processing another web app on sharing same session
What perfmon counters are useful for identifying ASP.NET bottlenecks?
Replacing ASP.Net's session entirely
The next step is to make a totally custom session.
Now, its may help if you use more than one pool (web garden) to run your site, but before do that you must be sure that you have correct synchronize your data and use Mutex and other locking mechanism for run on multi pool environment.
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.
In our Application_Start event handler we're performing some actions that intermittently fail due to file locking issues. In this scenario we would like to return the application to an "un-started" state.
By this I mean that the user will be shown an error page, and then the next time a user hits the site the Application_Start event will be fired again.
We're using ASP.NET 3.5, WebForms and MVC.
AppDomain.Unload offers what you're looking for, but I wouldn't recommend it.
There are lots of catches; tearing down an app domain programmatically is not without its own set of issues (i.e. if a thread's blocked in native code you may see a CannotUnloadAppDomainException) and is generally a poor design, IMO.
What you're attempting to do is highly unconventional; I would reconsider the approach all together. If you just need to execute some code once at the app domain level, there are lots of better ways to do it, like statics for instance or a flag in the HttpRuntime cache. Just mind the web-garden and concurrency scenarios.
Good luck.
I'm pretty sure that there is no way to quit/force stop an webForms application from within the application. However, an ungentle way to prevent the application from starting is to generate an unhandled error within your application_start. This will prevent start up from happening and upon the next hit to your webForms app, the application_start will try again.
I am writing a web application in ASP.NET 3.5 that takes care of some basic data entry scenarios. There is also a component to the application that needs to continuously poll some data and perform actions based on business logic.
What is the best way to implement the "polling" component? It needs to run and check the data every couple of minutes or so.
I have seen a couple of different options in the past:
The web application starts a background thread that will always run while the web application does. (The implementation I saw started the thread in the Application_Start event.)
Create a windows service that is always running
What are the benefits to either of these options? Are there additional options?
I am leaning toward a windows service because it is separated and can run on a different server (more scalable) as well as there is more control over when it is started/stopped, etc. However, I feel like the compactness of having the "background" logic running in the process of the web application might make the entire solution more understandable.
I'd go for the separate Windows service primarily for the reasons you give:
You can run it on a different server if necessary.
You can start and stop it independently of the web site.
I'd also add that it could well have some impact on the performance of the web site itself - something you want to avoid.
The buzz-word here is "separation of concerns". The web site is concerned with presenting the data to the user, the service with checking the integrity of the data.
You can also update the web site and service independently of each other should you need to.
I was going to suggest that you look at a scheduled task and let Windows control when the process runs, but I re-read your question and noted that you wanted the checks to run every couple of minutes. The overhead of starting the process might be too great in this case - though some experimentation would probably prove this one way or the other.
If you use a scheduled task there's also the possibility that you could start the next check before the current one has finished - something you can code for if you're in complete control.
Why not just use a console app that has no ui? Can do all that the windows service can and is much easier to debug and maintain. I would not do a windows service unless you absolutely have to.
You might find that the SQL Server job scheduler sufficient for what you want.
Console application does not do well in this case. I wrote a TAPI application which has to stay in the background and intercept incoming calls. But it did it only once because the tapi manager got GCed and was never available for the second incoming call.