Is there a difference between the threadpool that IIS uses to serve static resources and the threadpool ASP.Net uses?
Is it that IIS needs a thread to service a request, and if that request is for a managed resource (e.g. an ASP.Net request that will run managed code), then that request itself has access to a pool of ASP.Net threads?
How can the two values be configured?
How does the concept of a worker process fit into all of this?
Likewise, how does the concept of an application pool fit into this?
Related
How do I host both asp.net (to use SignalR w/ Azure's backplane) and WCF service (for fast binary netTcpBinding) in web-role (extreme budget issues...)?
I suppose both must be self-hosted, but how to wire up each of them to the hosting IIS in the VM (I believe they both reside in the same app-domain)?
(It's a continuation of "Is it possible to host both web/SignalR and WCF w/ netTcpBinding in a single web-role?")
If you're self hosting your apps, you do not use IIS and could go with a Worker Role (VM without IIS).
That would have the applications running in separate processes - hence different app-domains.
You sepcify the listening port of you asp.net application in the OWIN start method - e.g. Microsoft.Owin.Hosting.WebApp.Start("http://localhost:8080")
I am hosting a handler inside of a IIS web application. Is this a good solution ? Or Should I Hosting a handler in windows service application ? Which solution is better? What is recommended and what is more performance ?
I use SqlTransport in my configuration.
There are many factors that can effect how you choose to host your endpoint(s). For example
How you want to scale your site / handlers
What permissions can be granted to your web site process
How an IIS reset can effect your handling code
But in general... Host the bus in both the Web Application and a Windows service.
The web application handles incoming http requests, translates those requests to messages and places them on the bus via a Send.
The Windows service takes message off the bus and does the actual handling/business processing.
Some useful links that may guide you to the best solution for you circumstance
Hosting documentation http://docs.particular.net/nservicebus/hosting/ which contains some information on hosting in a web application
Windows Service Hosting http://docs.particular.net/nservicebus/hosting/windows-service
A showcase sample that uses a similar design as i described above http://docs.particular.net/samples/show-case/on-premise/
Web related samples http://docs.particular.net/samples/web/
Implications of Publishing from Web Applications http://docs.particular.net/nservicebus/hosting/publishing-from-web-applications
If you need to send messages from your web application then the only solution is to host NServiceBus in IIS, With IIS you shouldn't be publishing events from IIS.
Take a look here for more details
HTH
What is the defacto standard or best practice when it comes to increasing throughput and performance for an ASP.NET web service application?
Would there be any performance increase to method 1 below?
Utilizing the same directory/code, create multiple websites in IIS bound to different VIPs, all running on different application pools. Then use a network load-balancer to balance between the VIPs
Utilizing one website / application pool in IIS bound to one VIP; create additional VM instances and load-balance between the servers
Combination of both method 1, and method 2.
We've implemented a "background service" in our Asp.Net web app that receives messages from MSMQ at random intervals without requiring an HTTP request to start up the application. We auto start this web app using a serviceAutoStartProvider.
Everyhing works when IIS initially starts up, the server is rebooted and so on, we receive messages just fine. BUT if we just stop the site in IIS (not touching the application or app pool), the application stops receiving MSMQ messages. And when we start the web site again, the serviceAutoStartProvider is not called again, so our app does not start listening to MSMQ messages again!
If we issue a HTTP request against the web app after the IIS site has been stopped and started again, it starts listening to MSMQ messages again.
Shouldn't our "background service" web app continue to listen to MSMQ messages even if the IIS site is stopped? It won't get any requests, but I think it should continue to run.
What exactly happens in an Asp.Net application/app pool when the IIS site is stopped? Any events fired that we can hook up to? The app pool claims to be "started" in IIS manager, but code is not running in it.
Why isn't our serviceAutoStartProvider called when the site is started again? I believe it is "by design", since the application isn't really stopped. But the applications isn't running, either, has to be waken up by an actual HTTP request.
When the IIS Web App shuts down (eg. due to no new HTTP(S) requests for the timeout time) the .NET app domain (within the app pool worker process) completely closes and unloads. This includes all background threads, including those used by the .NET thread pool.
A Web App can be configured with a longer (or no) timeout, then background worker threads could continue to process work.
But better would be to either run such workers in a specialist service process managed completely separately.
Or, even better, use IIS application hosting with WCF to create the MSMQ listener. I understand in this case the integration of Windows Process Activation Services with IIS would restart the Web App if a new message arrived after it had been shutdown.
I would host the MSMQ listenner in a windows service. Why couple it to IIS?
UPDATE
Actually what I mean is why couple the MSMQ and ASPNET in the same app pool?
You can now use "Application Initialization" feature of IIS8 (and IIS7.5), more information including version availability and usage documentation can be found at:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
This replaces "Application Warm-Up Module" which is no longer supported, and provides us with proper control over component/service initialization in an "always running" scenario.
I am in a bit of confusion here. In IIS 5.0 all the ASP.NET applications run inside the same worker process(aspnet_wp.exe). The various applications are isolated by appdomain. I believe the fundamental functionality of an appdomain is to provide application isolation within a process. Now on to IIS 6.0. I have read about application pools in IIS 6. A lot of sites say that in IIS 5.0 when there is a problem with an application it affects the other applications. But isnt that safeguarded by appdomains? I am being told that application pools in IIS 6.0 prevent that mishaps. I am a bit confused here as to what exactly is advantage that application pools provide over IIS 5.0. I have also been told that in IIS 6 worker process isolation mode, configuring different application pools(and thereby different worker processes) is a perfomant thing to do. But spawning new processes increases the memory utilization and how can it be claimed to be a performant way to do things? Also how does the HTTP.SYS know to route the request to the concerned application poool?
Don't get application pools and AppDomains confused. An AppDomain is a isolation boundary within a process. They are designed to isolate and provide security around managed code that is executing.
Application pools are a feature of IIS that allow a pool to handle requests for multiple sites. They handle this by running multiple AppDomain instances in the worker processes (aspnet_wp.exe, or w3wp.exe). Although technically you can run multiple AppDomain instances per site, generally it is a single AppDomain per IIS Application.
If you have multiple sites in a single application pool (and this sharing the worker processes), if one of those sites starts consuming a lot of resources, this can directly effect the other sites running in the same application pool.
By grouping (and segregating) sites in logical groups (application pools), you can better manage how sites behave.
HTTP.SYS is a kernel mode driver stack that is part of the Windows subsystems. It provides management of the HTTP protocol in kernel mode (versions prior to IIS6 used winsock in user mode). With HTTP.SYS running at the kernel level, should a worker process fail, the request can be queued, and then forwarded to a new worker process which will be spun up.
When you create a site in IIS6, it registers the site with HTTP.SYS which can then route requests coming in to the appropriate worker process.
The Appdomain is about sharing data
http://msdn.microsoft.com/en-us/library/system.appdomain.aspx
and in IIS 6 you can append several applications to an application pool. If you have 2 applications in the same application pool and one of them keeps crashing, it affects the other and IIS will decide to shutdown the whole application pool because of the instability.
Therefore, if you have critical applications, it is recommended to keep them in their own application pool. If you have multiple apps in IIS, you route the requests with the hostheaders (or extra external IIP addresses)
extra resource that recommends an application pool for each production website: http://forums.iis.net/t/1151476.aspx
a nice resource which explains the difference between 5.0 and 6.0 with isolation:
http://www.tech-faq.com/understanding-iis-5-and-iis-6.html