First things first, Hope you all have a good Christmas :)
I've been a desktop application developer for the last couple of years but I'm now working on ASP.NET full time (job move :) )
So over the last few days, I've found my self wondering more and more about what actually happens when say a new visitor will visit my URL..
I've just been working on quite a simple Signal R based app and I have needed a few singletons to be shared across all sessions, now in desktop that's super simple but I'm not sure with the web at all :(
So basically, here is this question..
What actually does IIS do when say 5 people visit my URL, do they all get a separate instance of the app or do they use the same one? If you could break it down into simple terms, that would be fantastic! :)
Also, Say I've got a class library that has a static singleton - with that be the only instance of that class for the all the sessions?
Hopefully that makes sense :)
Thanks for any help!
cheers.
ste.
This is called IIS Life Cycle
The fully details must be direct read from Microsoft and the creators of the IIS.
Is not the same for all IIS.
Life Cycle Overview for IIS 7.0
Life Cycle Overview for IIS 5.0 and 6.0
and there are more if you search on internet.
do they all get a separate instance of the app or do they use the same
one
If you use many pools for the same application (web garden) then they the request are split among the pools, or else one pool, one instance is take care to process the page.
The page can be processing from different threads, but there is a global lock on the session, so if you use the MS session the page will processing in serial (expect the one that did not use session)
Each pool is one instance that hold the static data, and is the same for all request from that pool. If you use two pools you have two different sets of static data.
Some questions about session lock:
Trying to make Web Method Asynchronous , Web app blocked while processing another web app on sharing same session
If you have a default IIS install then you will have one app pool which will serve all requests. Therefore a static singleton will be shared by all 5 people in your example.
BUT if you ever need to scale out then you will have multiple app pools.
An app pool is an instance of your application.
If the statics are for database connections and similar then I would suggest you look at alternative methods so you don't need the statics. If it is something related to the business that your users are interested in then you would be best looking at other ways to share this between clients if you are going to need to scale.
Related
I have to see if I can work around a known thread safety issue on third party component. The plan was to let an ASP.Net app to talk to the third party component via a WCF service, this was based on the assumption that I will be able to assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread. Requests to the service will have to wait for their turn, but that's OK because we expect them to require very little time and to be rare as well.
Problem is, I can't find anything that suggests how to achieve this part: "restrict the working process to one thread".
I have found a few useful pages, but no solution:
On IISforums, the discussion seem to suggest that I can achieve this in IIS 7+ but does not mention IIS6.
On MSDN Blogs and linked MSDN books chapter (can't put the link because I'm new here!) the discussion is mostly about what you can set via the machine.config file, which, if I'm understanding it correctly, is going to apply to all AppPools/Worker processes and is not what I'm trying to do, I would like to control what one single app can do, leaving the other applications untouched.
Questions:
Is it possible to achieve what I'm trying to do? (assign the WCF service to it's own application pool, restrict the pool to one working process and the working process to one thread" via IIS 6 configurations)
If not, can this be achieved programmatically somehow? For example, using locks or other threading-related tricks within my WCF service implementation.
It doesn't make much sense to me.. A web server have to be multithreaded by definition, because it must handle different income messages at the same time, if there is only one thread once in use any new request will fail.
What about to wrap the component in a class with a SynchonizationAttribute, so only one thread can access the component? Even if this will make your solution less scalable, at least it may work
http://msdn.microsoft.com/en-us/library/system.runtime.remoting.contexts.synchronizationattribute(v=vs.110).aspx
I have downloaded TheWorldsWorstStackOverflowClone. One of the project is called TheWorldWorsts.ApiWrapper, which basically is the core of accessing the API. There is a class called ApiProxy.cs, which has all the methods for the API call. This is good.
Now what I want to do is I am trying to collect data from this API interface and store it in a database. I know the limit to the API call is 10k per day. I.e: I want to be able to call the method in the ApiProxy class 10k times per day, done automatically. How can I do this?
The non-automatic way would be to create a dummy site where when every time I access the site it does all that process, but this not efficient. It seems that I have to write some kind of a scheduler by deploying a web service, but that is too complicated... as explained here. Any other simpler methods?
A Windows Service or Desktop App might be a better solution than a web application. You are not deploying a web service, you are consuming one using a proxy class, and this does not require you to have a web server or a web site.
You could use a web application to control and monitor progress as your service downloads data, but the actual work is long running and needs to be offloaded to another process or thread so you can tell the user whats going on.
Check out this one
http://stacky.codeplex.com/
This looks what you need, though I am facing some debugging issues, but hope you can figure it out.
I came across a case study few days early. It is related to a web application architecture.
Here is the scenario,
There is a single web service used by say 1000 web applications. This web service is hosted on a particular server. If web service hosting location is changed, how the other applications come to know about this change ?
Keeping it in web.config doesn't seems to be a feasible solution as we need to modify web.config files for all the applications.
Keeping these settings in a common repository and let all the applications use it for web-service address was came in my mind, but again there is a question of storing this common repository.
I am just curious to know about how this could be achieved with better performance.
Thanks in advance for any kind of suggestions.
do you have full access or control over all those web applications consuming that web service? if so, you could have a script or some custom code which updates all their web.config(s) at once. it seems too much work but in fact in this way you have more control and you could also, eventually, point to the new url only some applications and leave some others on another url.
the idea with the setting in a centralized database gives you faster update propagation which could also be bad in case of errors and then you have all applications referring to the same place and no way to split this. Then you have anyway to connect to a centralized database from all of them and maybe you should add a key to their web.config(s) with the connection string to that database, then, in case that database is not reachable or is down, the web applications will not be able to consume the web service simply because they cannot get the url of it.
I would go for the web config, eventually you could have a settings helper class that abstract the retrieval of that url so the UI or front end does not know from where that url comes from.
anyway, do you plan to change the url of a web service often? wouldn't be better to copy it to a new url but to also keep it available on the current url for a while?
another advantage of web.config approach is that everytime you update and save it the application is restarted while a change in a database might take a while to be detected in case you have some caching mechanism,
hope this helps.
Davide.
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.
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.