My undersatnding on ASP.Net is when a request comes, ASP.Net uses a internal thread from thread pool to do the work and respond. Correct me if I am wrong. If that is the case, will I able to get a control on this asp.net thread pool?
You cannot interact with the thread pool directly though. However, you can manipulate some of the characteristics of the thread pool by setting the processModel in your web.config .
To my knowledge that information is not available to your application.
What is it you are trying to accomplish?
Related
I've been reading a lot about how IIS manages threads for http requests (taking them from the pool once needed and "releasing" once the request has been processed)...
And about the whole concept of async requests in, for example, ASP.NET MVC that are used to "release" threads back to the pool when long-wait I/O operations are executed on the side.
But what I can't understand is - if I start "normal" threads using Thread.Start() - these threads are "unpooled", right? And they don't use up the IIS request thread pool - is this correct?
I tried Googling but can't find the exact answer. I know that Thread.Start does not use the .NET's built-in ThreadPool at all - but I have doubts about IIS using the same mechanisms for its request threads, could it be that IIS "request pool" is different from the .NET's ThreadPool and uses some lower level pool, so that my Thread.Start will also end up there?
I guess what I'm asking is - is there a limit on Thread.Start() in an ASP.NET app and can a lot of Thread.Start's block my web application during a high load because of thread-queuing?
UPDATE: found this answer but it does not explain why and what happens: Why ASP.NET kills my background thread?
Consider the following code which runs in an ASP.Net web application on IIS...
_thread = new Thread(Method1)
_thread.Start();
As there is a thread pool within the ASP.Net process what is the effect of this code? Specifically...
Will it take another thread from the ASP.Net thread pool? Or from a different threadpool? Or does this code bypass the thread pool and just get a new thread?
Is this the same thread pool that is used to serve page requests? Therefore, this code which was put in to improve performance could actually reduce it by taking another thread that could be used to serve another resource to another user?
Is the thread pool only used for serving non-static resources? Does IIS have it's own thread pool for serving resources that do not run through the managed pipeline?
What would happen if the App. Pool was recycled after calling _thread.Start()? Would IIS allow this thread to complete before closing down the application pool?
It seems to be that this code forces the creation of a new thread. Would there be a benefit to swapping this code to use Async/Wait? The code that runs in Method1() is IO bound.
When you call new Thread explicitly, that thread is not part of the thread pool. You are fully on your own.
The so called ASP.NET thread pool is purely used to process request messages (to host HttpApplication derived objects).
Static files are served by IIS natively, so the ASP.NET thread pool is for ASP.NET contents only. But here you should notice all happens inside the worker process (w3wp.exe). Just some are processed by native components, while others are by managed components. The pipeline is unified if you are using the integrated pipeline mode.
Application pool recycle only waits for requests to be processed. Your own threads will be killed when all requests are done.
Async/await does not create threads automatically. But by switching to async/await, you do avoid create a thread, and that should help improve performance.
ASP.NET 4.5+ (the one where you can use async-await) uses the same thread pool to handle requests and to schedule task execution through Task.Run.
When you use Task.Run when handling an ASP.NET request, you'll be changing context to a new thread pool thread and returning the current thread pool thread back to the thread pool. When the task completes, you'll be switching back another thread pool thread.
Using Task.Run when handling an ASP.NET request requires, at least, one more thread pool thread and incurs in, at least two context switches.
The bottom line is that it requires more resources and takes more time to handle the request.
Who is the user/identity which executes the function specified within a Task.Run? Is it the application pool?
Is it the application pool?
Yes. There are a few exceptions, but that would be you making it do something different, then you would know because you wrote it. Otherwise:
Task.Run()
Will execute on the current thread or a new thread with the same Credentials (as the thread that spawned the new thread).
Don't confuse the Threads credentials (app pool, or configured otherwise in the web.config) with the HttpContextBase.User Property which is the person who made the request.
All threads run as configured in the web.config, unless you've explicitly change that threads credentials.
(I say otherwise configured as you could use IIS Impersonation to allow the thread to impersonate the HttpContextBase.User but please don't ever use impersonation).
This is ASP.NET ASMX Web Service / .NET Framework 4.0.
In web service, I want to execute one method on another thread something like “Fire and Forget” so that Web Service returns some value in response immediately to web site. That method on another thread could take 10 minutes after Web Service returns response immediately to Web site. Also, I do not need return value of that method.
I have tested this scenario using ThreadPool.QueueUserWorkItem and it seems that thread started using ThreadPool will still keep executing even after Web Service returns response back to Web site. Am I correct here? Also is there a better way to achieve this?
The problem is that every now and then, ASP.NET will recycle the app pool. Because it doesn't know about your background task, it will not be considered and will be aborted when the AppDomain is disposed.
Most of the time, the work will complete, but if you run for long enough, you will encounter this scenario.
There are two solutions:
1) The "proper" way is to write a Windows Service that runs outside ASP.NET. You can send instructions to the Service over WCF.
2) The "quick and dirty" way is to write a hidden web service in your ASP.NET site that is never called by users. Your app starts an asynchronous request to the hidden service and then returns its own result to the user, without waiting.
ASP.NET does not know that the request to the hidden service came from inside your app - it just treats it as another request. Because ASP.NET knows about this request, it will not abort it when it recycles.
I have made an asp.net page which executes a long sp.
lets say the the function that executes the sp is called Func1.
Ive met with that problem :
If i ran Func1 in the same thread ( normal execution), the apppool won't recycle itself since he's seeing it as a busy/working.
But if I execute Func1 in another thread - so the apppool recycle's itself after the time that is set here :
My question is : why is that ?
is it true that if i run a command synchronously , so app is active and not eligible for apppool recycle ?
And if i create it in a new thread so it does eligible for apppool recycle ?
why is that ? Does the thread is less important then the main thread ?
ASP.NET maintains a list of thread pool threads that it is using to service requests. It knows it can recycle the app domain when none of its threads are active.
If you create a thread or use a thread pool thread without the knowledge of ASP.NET, it will not detect that your thread is active and may recycle.
When it recycles, it unloads the AppDomain which causes a ThreadAbortException to be thrown on your thread.
The normal solution to your requirements is to have a windows service that is controlled by the web app. This is obviously in a separate process and so is not affected by the web app recycling. However, this is a non-trivial exercise.
The quick-and-dirty solution is to asynchronously start a web request from within your web app. The page that starts the operation can then return. The "hidden" page that was called can block until the SP has completed. As I said, this is a nasty-but-easy solution.