Administrator
VB.NET Forum Admin
- Joined
- Jun 3, 2004
- Messages
- 1,462
- Programming Experience
- 10+
I'm interested in your opinions on asp.net applications launching tasks on a background thread. Particular interest are asp.net sites in a shared hosting environment.
Are there infinite threads available, or is the thread pool finite, and if so, how many background threads can be launched?
The reason I ask such a question is I'm seeing ASP.NET developers build add-on applications that run inline with a busy web site, i.e. a shopping cart/e-commerce app and I'm trying to gauge the impact of developers abusing background threads. What I'm really getting at is....my concern is that running add-on functionality (third party products to existing e-comm sites) that claim they are "no/low impact" because they run in a background thread, is in fact contrary to the truth.
My philosophy, and correct me if I'm wrong, is that your app may claim to run on a background thread, but really, this app should never be running inline with this site in the first place. There are a finite number of threads and there is still a penalty to create your object and pass it to a background thread, therefore your app DOES impact the asp.net web site. People are using the Session_OnStart() to launch their background threaded apps and it has me concerned.
Now take this, as I stated in opening, that on a shared hosting environment, this could be a real problem.
So threading guru's, I'm curious of your response since .NET makes threading so easy. How many "threads" are there, is it a factor or not if we have 50 wb sites on a server running a system that throws actions to a background thread. Will this web site feel the impact, or will it handle all background thread submissions seamlessly without the web visitor ever noticing a delay in starting their session?
Are there infinite threads available, or is the thread pool finite, and if so, how many background threads can be launched?
The reason I ask such a question is I'm seeing ASP.NET developers build add-on applications that run inline with a busy web site, i.e. a shopping cart/e-commerce app and I'm trying to gauge the impact of developers abusing background threads. What I'm really getting at is....my concern is that running add-on functionality (third party products to existing e-comm sites) that claim they are "no/low impact" because they run in a background thread, is in fact contrary to the truth.
My philosophy, and correct me if I'm wrong, is that your app may claim to run on a background thread, but really, this app should never be running inline with this site in the first place. There are a finite number of threads and there is still a penalty to create your object and pass it to a background thread, therefore your app DOES impact the asp.net web site. People are using the Session_OnStart() to launch their background threaded apps and it has me concerned.
Now take this, as I stated in opening, that on a shared hosting environment, this could be a real problem.
So threading guru's, I'm curious of your response since .NET makes threading so easy. How many "threads" are there, is it a factor or not if we have 50 wb sites on a server running a system that throws actions to a background thread. Will this web site feel the impact, or will it handle all background thread submissions seamlessly without the web visitor ever noticing a delay in starting their session?
